From this point of view, what "fetch, merge and then push" is not quite a right suggestion to proceed from a failed push due to "non fast-forward".
Git rebase fast forward how to#
If the current branch and the remote have diverged, the user needs to specify how to reconcile the divergent branches with -rebase or -no-rebase (or the corresponding configuration option in pull.rebase ). In reality, E in the illustration may not be a single commit but can be many commits and many merges done by many people, and these many commits may have been observed as the tips of the upstream’s history by many people before F got pushed.Įven though Git treats all parents of a merge equally at the level of the underlying data model, the users have come to expect that the history they will see by following the first-parent chain tells the overall picture of the shared project history, while second and later parents of merges represent work done on side branches. If the current branch is behind the remote, then by default it will fast-forward the current branch to match the remote. The branch had a single commit (and could have had several) before the merge. Consider the following branch and then merge situation: The green branch and the blue main branch both have the 45tP2 commit in their history. The merge result records D as its first parent (denoted with 1 on the edge to the parent), as if what happened on the upstream (E) were done as a side branch while F was being prepared and pushed back. In certain situations, Git does a fast forward when you merge a branch that is ahead of your checked-out branch.
However I was still able to pick a different merge strategy when I was about to accept the pull-request.Īs far as I know GitHub does not support requiring fast-forward when you accept and merge a pull-request.Īs I can see one can set fast forward merge as the only acceptable merge strategy.The resulting history, however, is not what the majority of the project participants would appreciate. It indeed stopped me from accepting a pull-request that could not be merged using fast-forward. The documentation seems to indicated that the admin of a project can set theĪvailable merge strategies, but all I managed to do was to set the default merge strategy. Among the several features one can Enforce a merge strategy, but as far as I can see only No fast-forward merge and Squash merge are available. In Git tips: Use only fast-forward merges (with rebase)īranch policies. This is also describe by Marko Vuksanovic git/config file of your project will enforce the "merge only with fast-forward" rule on the "master" branch only.
Of course all this is on the client side and not on the server.Įnforce fast-forward to a single branch onlyĪdding the following to the. This way the enforcing only happens in specific projects. That basically forces you to either rebase before merging, or turn off this configuration, or to force your way through usingĪlternatively you can execute the following command while inside a git workspace That will add an entry to your ~/.gitconfig file:Īnd it will require that you only merge branches that can fast-forward. A follow-up article called Git Merge vs Rebase and Where to Use Them will cover the pros and cons of each workflow. Only Allow Git Fast-forward Merges to Avoid Ugly Merge Commits and he suggested execute There are several ways to enforce it or at least to gently nudge you in the chosen direction. This question already has answers here : shortcut for git merging master into current branch (3 answers) Closed 8 days ago.
0 kommentar(er)
