The classic usage of git is to work with a remote repository.
Let’s consider Adele and Blair, 2 developers working on the project paris, which is also the name of the repository they are both working on.
Blair starts by cloning the repo.
Adele is now the proud of owner of a brand new commit on her machine:
Adele starts to work on that repo and eventually has a commit ready to be pushed.
Adele’s commit tree is now:
Adele continues her development and has a new commit ready:
But this time, when she tries to push to her origin server:
The dreaded git error message.
The git status command doesn’t give a lot of information… besides the fact that Adele must push her commit:
In that specific scenario, the reason for the rejection is easy to guess: her friend Blair has already pushed a new commit to master.
You can vizualize the problem by looking at the commit tree on the server.
On the paris remote repository, the commit tree is:
There is now a new commit (2251) that Adele doesn’t have locally, but Adele has a commit (7111) that the remote doesn’t have… Bummer.
One way to solve that situation is to follow git’s recommendations and perform a git pull:
The commit tree on Adele’s machine looks like this now:
The git pull command has created a merge commit (e449) to reconciliate the local commit (7111) and the remote commit (2251).
Forget the wars vi vs emacs or space vs tab : some developers have an allergic reaction when they encounter merge commits and they would get crazy if they see a commit tree like above.
We’ll see at another time how to avoid this merge commit and, by doing so, to prevent the end of the civilized world.
After this git pull, Adele has now 2 commits that the remote doesn’t have:
Time for another push to sync up the remote and Adele’s machine:
And now, the remote has the same commit tree as Adele’s machine: