Remote Repositories and Synchronization - Git Recipes - page 348

The situation shown in Figure 10-9 is much more complicated. The master
branches in the shared repository and in John's repository have diverged. John's con-
tains a4 and a5 and the shared repository contains b3 . Thus $ git push origin
master executed by John in the repository shown in Figure 10-9 fails. Git prints the
information that John needs to fetch the revisions from the remote repository first.
When used with -u parameter, the $ git push command stores the information
about tracking. The command:
$ git push -u origin master
executed by John when he pushed his a1 , a2 , and a3 revisions created in John's re-
pository the remote tracking branch remotes/origin/master . The master
branch was set as a local tracking branch for origin/master branch. You need this
parameter only in the very first call to $ git push .
The new command used in this repository is $ git pull origin master .
This command copies the revisions from the remote repository pointed by origin .
The revisions are copied from the remote master branch and then merged with the
current master branch in the local repository. If the operation can be performed as a
fast-forward then there is no merge commit. This is the case when you changed the
state shown in Figure 10-6 into a state shown in Figure 10-7 . When local and remote
branches diverged, then the command generates a merge commit. That's why we have
the merge commits shown at the top of Listings 10-1 and 10-2. The merge commit ap-
peared in johns-repo when you changed its state shown in Figure 10-9 into the
state shown in Figure 10-10 .
How committing affects tracking branches
We again analyze how tracking branches change during a commit from the perspective
of Sarah's repo. Right after $ git clone shared-repo sarahs-repo the re-
positories shared-repo and sarahs-repo look like Figure 10-13 .