Growing commit list on each pull request having squash merge strategy on master branch

Issue #16795 resolved
Michal Zukowski created an issue

I have two branches: master and staging. The master is write protected, allows only pull requests and the merge is made using the squash strategy.

Given that, when creating each new pull request, the automatic description of the pull requests contains LOTS of commits from the staging branch. They were merged already, however, since they do not exist in the master branch (each merged pull request results in a single merge commit) the list keeps growing and growing. On each pull request we have to clear that description and leave only relevant commits which is a tedious work.

Maybe we're doing something wrong? However this sounds like a bug ;/

Comments (4)

  1. Daniel Tao staff

    Thanks @michalz_plocman for the clear description! This is not a bug. The simple explanation is that you are combining two incompatible development strategies: long-lived branches, i.e. as prescribed by Gitflow (on Bitbucket we use this approach for some of our repositories); and squash merge, which is all about maintaining a linear history.

    For any strategy involving long-lived branches, it is important that your long-lived branch (staging in your case) and your mainline branch (master) maintain parallel histories, by which I mean the same set of commits. Releases—where you merge the head of your long-lived branch into your mainline branch—consist of identifying all of the commits in the former and not in the latter, and merging those in. When you use a squash merge strategy to do this, you are effectively creating a new commit in the mainline branch, without merging in any of the commits from the long-lived branch, so that the two branches now have effectively different histories.

    Hopefully that explanation makes sense. What I suspect you should be doing instead is something akin to what is described in the Atlassian article on Gitflow that I referenced above: do your development work on (short-lived) feature branches off your staging branch, and use the squash merge strategy to get those changes onto staging. This way, your staging branch will have a clean linear history, so that when you want to merge the latest changes from staging into master you can use a merge commit—or even our fast-forward merge strategy—to maintain the same history on both.

  2. Log in to comment