Home > other >  What is the proper way to merge to master?
What is the proper way to merge to master?

Time:10-06

Say I have a develop branch with 10 commits that can be squashed down to one. I go to GitHub and do a "Squash and Merge" and it gives me the option to delete my branch. I want to keep this "develop" branch for other updates but now this branch is considered Ahead of master. What do I do in this case? If I delete it, how do I create a new branch with the same name without messing things up?

CodePudding user response:

As the Git FAQ states, you don't want to keep two long-running branches where you merge one into the other with squash merges because this can only result in merge conflicts and sadness.

If you want to keep using the same branch (develop) for your PRs, then you can recreate the branch on the local side off of master with git checkout -B develop master. However, if you do that, you will need to force push the develop branch unless you've deleted it from the remote first with git push -d origin develop or through the interface.

Alternatively, you can use regular merge commits and the problems outlined in the Git FAQ will go away, and you can keep using the develop branch essentially indefinitely.

CodePudding user response:

Long-running branches, where one of them is merged multiple times into another, constitute something of an anti-pattern in Git. This is one of the reasons why the original Git flow was so surprising; it uses that pattern.

If you think about how merge works, you can see what the problem is. A merge commit revolves around the merge base, which roughly speaking is the commit from which both branches originally split. When you squash merge develop into master and keep develop alive, the merge base doesn't move. Thus every merge after that is going to have to take account of all those same commits plus all the new commits on both sides, including your squash commit on master. This means you'll keep getting further and further ahead and behind, plus there is increased likelihood of a merge conflict.

One solution is: Don't do that. Just merge and then delete the develop branch. Now create a new develop branch off of the new end of master and away you go. Remember, a branch is incredibly lightweight; it is nothing but a name for a single commit. Destroying and creating the name is no trouble at all.

If you do decide to keep develop alive, then for heaven's sake don't use squash-and-merge. It is not a merge! It creates a commit on master out of whole cloth, bearing no topological relation whatever to develop. You have thus destroyed history completely, both for yourself and for Git.

So my advice would be, if you must keep develop alive, use true merges. Then, the next time, just before you merge develop into master, do a reverse merge where you merge master into develop. The result is that you move the merge base forward, plus you have an opportunity to grapple with any merge conflicts before doing the forward merge.

  •  Tags:  
  • git
  • Related