Additionally you can do git log -first-parent to traverse only the main commits (blue). gitk) are able to represent such history nicely. In the correct history (left) it’s clear how the different topic branches are integrated into “master” (blue). Let’s say the project allows merges, in that case it’s OK to just do git pull (since the default action is merge) right? People should be doing git fetch instead and then decide whether to merge or rebase if the branches have diverged (a fast-forward is not possible). So that’s the first problem: git pull creates a merge commit by default, when it shouldn’t. By default git pull does a merge, so that’s what most people end up doing by omission, but that’s not always right. We are still nowhere near a universal answer, and what do most people do when the answer is not clear? Nothing. Most experts would do a rebase, but if you are new to git a merge is easier. If you don’t do many changes then most of the time you can fast-forward. Other projects prefer to keep the history intact, so it’s fine if you merge. Some projects prefer a linear history, in those cases you must rebase. OK, so if the branches have diverged you have two options ( merge or rebase), which one should you pick? The answer is: it depends. In this case the diverging commit of the local branch “master” (D) is recreated on top of “origin/master” (C) so the resulting history is linear (as if it never had diverged in the first place and the base of the local branch was C). fast-forwardĪ fast-forward is simple: if the local branch and the remote branch have not diverged, then the former can be easily updated to the latter. In Mercurial hg pull is the equivalent of git fetch, so in Mercurial hg push and hg pull are symmetric, but not in git.Īt some point in time a path to make git pull be symmetric to git push was delineated, but the maintainer of the Git project considered it “ mindless mental masturbation“, so forget about it.Īfter you have pulled the changes with git fetch, then there’s two possibilities: fast-forward and diverging.
Git pull origin master commit how to#
The mirror of git push is git fetch which simply pulls the remote changes locally so you can decide later on how to integrate those changes. OK, so we need to “integrate” the remote changes with git pull, so presumably git pull is the mirror of git push, so it makes sense.Įxcept it’s not, and git pull was never designed with this use case in mind. Hint: See the 'Note about fast-forwards' in 'git push -help' for details. Hint: 'git pull …') before pushing again. Hint: Updates were rejected because the tip of your current branch is behind
! master -> master (non-fast-forward)Įrror: failed to push some refs to 'origin' “origin/master”), in particular because if they don’t, git push fails with: To origin “master”) with the corresponding remote branch (e.g. What most people want to do is synchronize their local branch (e.g. The rest of the article is with them in mind, who unfortunately are the vast majority of users, especially novices. That leaves developers who work on a centralized workflow (e.g. If you are a developer (non-maintainer), and use a topic branch workflow, then you don’t even need git pull. It was created for maintainers: when you send a pull request, a maintainer is supposed to run git pull on the other side. Let’s start by explaining where git pull is not broken. The problem is that the short version is actually too short:īut why? Even thought it’s obvious for me, and many other developers why git pull is broken and should not be used by most users, presumably a lot of people don’t know that, since they continue to use it. A lot of people complained that my previous post– git update: the odyssey for a sensible git pull–was too long (really? an article documenting 13 years of discussions was long?), and that a shorter version would be valuable.
0 kommentar(er)
