Question

Let’s say that there are two people working on a git branch, they check out at the same time but one of them commits first and then the other commits after. Will the newest commit still be merged with the former commit or can multiple people work on the same branch simultaneously?

Answer 1

Well, when you clone a git repository (is that what you meant by “check out”?), you’re effectively creating a new branch. Git branches are local to each repository, not global. Having said that, you have a protocol for how updates to branches are transmitted between repositories– when you pull from a remote, by default the remote’s “master” branch gets merged into your “master” branch, for instance. And when you push, your “master” branch can be appended to the remote’s master branch. So your master and remote’s master (“origin/master”, if you will) are different branches, but related by convention.

Getting back to the point— you notice I said your master branch can be appended when you push to a remote. If two people have taken a copy of origin/master and made independent changes (remember this is just like making changes on two branches locally), once one person has pushed their changes, the other’s person’s changes aren’t a simple append onto origin/master any more— they have to be merged. This can’t happen when you push, only when you pull (confusingly, “pull” isn’t quite the opposite of “push”: “fetch” is the opposite of push- a pull is a fetch followed by a merge (or a rebase)).

So if you’re in this situation, whoever is trying to push their changes first needs to pull back from the updated origin/master, merge or rebase their version of master, and then push. By default you can’t remove someone’s changes to a branch and replace them with your own: you need to at least do “git push -f” to do that, and the remote repository can have settings or hooks to make it considerably harder.

Or the two of them could cooperate beforehand: one of them pull the other’s changes, do the merge, and then push the result. This can be a good thing to do if it’s likely the changes are going to overlap or affect each other. Remember the First Law of version control systems: a VCS is not a replacement for communication.