What to use instead of git pull

Question

Here is the situation: (P means people here).

P1 and P2 created their own branches, devP1 and devP2, from master.
P2 just ended their work, so they merge with local master then they pushes on the remote master repository. All is fine.

But then, P1 ends their work too, so they are doing the same thing, merging with the local master, then trying to push. But obviously, the remote master is ahead than their local one, and they can't push.

In this case, I used to just pull the master branch in those kind of situation, but someone recently told me this was very bad because I was creating a merge commit, which one was irrelevant or at least meaningless.

That's when they lost me and I haven't been able to understand what I'm supposed to do in those kind of situation. Is someone can explain to me what to do here? Some kind of rebase maybe? But I can't really rebase a remote branch right?

Thanks for your help and explanation. I haven't been able to find this anywhere.

Answer 1

I suspect what your interlocutor had in mind was in fact using a git rebase instead of a merge. Consider the following simple diagram which will demonstrate what a rebase is.

master: ... A -- B -- D
local:  ... A -- B -- C

The above diagram attempts to represent the state of the branches when P1 attempted to push his work. Both his local branch and the remote master are identical up until commit B. But P2 has pushed commit D on top of master, and then P1 made commit C locally. If P1 were to pull the remote master, merge, and then push, we would have the following diagram:

master: ... A -- B -- D -- M'
local:  ... A -- B -- C -- M

Now we see that both the local and remote master branches have merge commits (labelled as M and M'). However, there is an alternative here. P1 could have rebased his local branch on the remote master branch, via this:

git checkout local
# do a fetch if not up to date already
# git fetch origin
git rebase origin/master

Now here is what the diagram would look like after rebasing:

master: ... A -- B -- D
local:  ... A -- B -- D -- C'     (C' labelled as such because it is a new commit)

Pay attention here, because what rebasing has done is to rollback the local branch to the most recent common commit between itself and master, which is commit B. Then, it replays the commits from master, which in this case is just commit D. Finally, it applies the commits which were unique to the local branch, in this case commit C.

The nice thing about this, which you can hopefully see, is that P1 can now just do a normal git push to bring his commit into the remote master:

git push origin master

This would leave the diagram looking like this:

master: ... A -- B -- D -- C'
local:  ... A -- B -- D -- C'

Now there is no merge commit on the remote master branch.

Note that rebasing usually involves rewriting the history a branch, and this can have complications if the branch being rewritten has already been shared publicly. In the case of P2, if his local branch is being used only by him, then there is no penalty for rebasing it. The remote master branch was not rewritten by the exercise we did above. But this may not always be the case, and is something to keep in mind.