DailyRNG
Login
Basic

Letting other people in

I pushed to a repo that did not exist yet and got an error I did not understand. It turns out you cannot share work that has nowhere to go.

What you will see

Rebasing abc..def onto def Successfully rebased and updated refs/heads/main.

About 2 min of reading

Try It

I pushed to a repo that did not exist yet and got an error I did not understand. Let me name a remote, send my work out, and see why sharing needs a place to land before it can be shared.

1

A remote is a second copy of your repository somewhere else, GitHub, GitLab, a colleague’s machine. Right now the only copy is here, so there is nowhere to send the work. git remote -v lists the copies git already knows about, and this is a brand new project, so it prints nothing.

git remote add origin https://github.com/ada/myapp.git git remote -v

Before you run it, say out loud what it will print. Then open the answer.

What it prints
origin https://github.com/ada/myapp.git (fetch) origin https://github.com/ada/myapp.git (push)
origin is just the conventional name for your main remote, like calling your laptop "my computer". You can add more later if you mirror work somewhere else.
2

push uploads your commits to the remote. The very first time, add the -u flag so git remembers this remote and branch as the default. After that, a plain git push is enough and I stop retyping the address.

git push -u origin main

Before you run it, say out loud what it will print. Then open the answer.

What it prints
Enumerating objects: 6, done. Writing objects: 100% (6/6), done. To https://github.com/ada/myapp.git * [new branch] main -> main
If the remote is a shared project you did not create alone, skip -u on later pushes. It is only for the first time, and reusing it on an established branch is harmless but pointless.
3

pull downloads commits others have pushed and merges them into your branch. It is the opposite of push. I forgot it once and came back to a project that had moved on without me, a quiet kind of pain. pull keeps you in sync with everyone else.

git pull

Before you run it, say out loud what it will print. Then open the answer.

What it prints
remote: Enumerating objects: 3, done. Updating abc..def Fast-forward notes.txt | 1 insertion(+)
pull merges the remote work into your branch immediately. If you would rather look first and decide later, fetch instead, it grabs the latest but leaves the merging to you.
4

fetch is the cautious cousin of pull. It downloads the latest commits but does not merge them, so you can look before you integrate. Useful when you want to see what others did without changing your branch.

git fetch

Before you run it, say out loud what it will print. Then open the answer.

What it prints
From https://github.com/ada/myapp * [new branch] feature -> origin/feature
fetch updates your remote-tracking info but does not touch your working files. After it, read origin/main or the feature branch before you decide whether to merge.
5

The three in one row so they do not blur together. push sends, pull downloads-and-merges, fetch downloads-only. When in doubt about what changed, fetch first, decide, then pull.

git fetch; git pull --rebase

Before you run it, say out loud what it will print. Then open the answer.

What it prints
Rebasing abc..def onto def Successfully rebased and updated refs/heads/main.
pull rewrites history by replaying your commits on top of the fetched ones. Do not rebase a branch anyone else is already reading; it is fine for your own local work.

Data Flow

Commits travel out through push and come back through pull, keeping everyone in sync.
1 Push commits to the remote
↓
2 The remote stores them
↓
3 Others fetch or pull
↓
4 Their branches update
↓
5 Everyone stays in sync
Why this works
What a remote actually is

A remote is simply a copy of your repository hosted somewhere else, GitHub, GitLab, a second computer, a colleague's machine. That's not a branch, and it isn't cloud magic, just another folder git knows how to talk to.

git remote -v   # list your remotes

Your local commits are private until you push them. The remote is where shared work goes to live.

push, pull, fetch

These three look similar but do different things:

git push     # send your commits out
git pull     # download and merge others' commits
git fetch    # download only, without merging

fetch is the cautious cousin of pull: it grabs the latest work but leaves the merging to you. Use it when you want to look before you integrate.

Examples

Name your remote host

git remote add origin https://github.com/ada/myapp.git

This links your local project to a copy that lives on GitHub (or any other host). origin is just the conventional name for your main remote, like calling your laptop "my computer". You can add more later if you mirror your work somewhere.

Send your work out

git push -u origin main

push uploads your commits to the remote. The first time you do it, add the -u flag so git remembers this remote and branch as the default. After that, a plain git push is enough, which saves you from retyping the whole address.

Bring other people's work back

git pull

pull downloads commits others have pushed and merges them into your branch. This is the opposite of push. I forgot it once and came back to a project that had moved on without me, a quiet kind of pain. pull keeps you in sync.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← Reading your own history
Previous Lesson
Reading your own history
Next Lesson
The merge that refused to cooperate
The merge that refused to cooperate →