Remote Repositories and Synchronization - Git Recipes - page 347

git rebase , $ git cherry-pick , and $ git commit --amend com-
mands. When you work in your local repository there is no method to copy the existing
revision—all you can do is to create a new database object with a new SHA-1 name.
On the other hand, during the $ git push and $ git pull commands the revi-
sions are copied not recommitted. The copied object has the same SHA-1 as the origin-
al.
In this recipe we used two commands to send and receive revisions to and from the
remote repository:
• $ git push —sends the revisions from local to remote
• $ git pull —downloads the revisions from remote to local and then
merges them with appropriate branch
These commands were used with the two parameters:
$ git push origin master
$ git pull origin master
In both cases origin is the name of the remote and master is the name of the
local branch.
The first command, $ git push origin master , sends the local branch to
the remote repository. To be more accurate, we can say that the command sends the
missing revisions from the local repository to the remote end and then updates the
branches (remote branch and remote tracking branch—we will discuss this soon).
When John executes $ git push origin master for repositories in Figure
10-2 , first git copies three revisions a1 , a2 , a3 from the database in johns-repo to
the database in shared-repo , and then updates the branches.
By default, git restricts the $ git push operation to fast-forward cases. This
means that $ git push succeeds only when the remote branch can be fast-forwar-
ded with your work. This is the case when John changes the state from Figure 10-2 into
the state shown in Figure 10-3 . The repository shared-repo in Figure 10-2 is
empty; therefore it can safely receive the three commits a1 , a2 , and a3 . The same will
happen when Sara changes repositories from Figure 10-5 into the repositories shown in
Figure 10-6 . The repository shared-repo shown in Figure 10-5 contains the revi-
sions a1 , a2 , and a3 . It doesn't contain the revisions b1 and b2 , which are ahead of
a3 in sarahs-repo . The master branch in shared-repo can be fast-forwarded
with the b1 and b2 revisions, therefore the operation succeeds.