57

I am going to merge my release branch to master and I am wondering if I should squash the commits from develop into a single merge commit when merging into master.

General documentations about git flow contain figures like this one from in the Atlassian page:

enter image description here

In those figures only single commits appear on master instead of all commits made to develop.

Acctually, I like the idea of having a master branch which release commits only.

Should I retain all commits on develop when merging into master? Or do you squash the commits before merging to master when following Gitflow?

Link to the source article: Gitflow Workflow - Atlassian

MPatel1
  • 391
  • 8
  • 11
Rika
  • 671
  • 1
  • 5
  • 7
  • 3
    I think the OP is asking about what the standard practise is when following **gitflow** - is it to squash and merge release branches or simply merge them? – GrayedFox Apr 08 '18 at 15:43
  • 2
    Can you provide a link to the atlassian page where you got this image from? (for the benefit of future readers) – SunnyPro Sep 20 '19 at 21:52

4 Answers4

49

In my opinion, and bear in mind, this is just an opinion, and you will likely get different answers, you should NOT squash the commits when merging into master from the develop branch. Doing so would lose a lot of the history of the changes that have been made. For example, almost all the commits I make are tagged with an issue number, so that there is full trace-ability back through the git history into the issues that were raised, and why changes were made.

More to the point, you shouldn't be merging directly from develop into master. Assuming you are following git-flow, then this transition should be being done through a release branch.

If you had asked whether, when on a feature or hotfix branch, should the commits be squashed then that would have been a different answer. In these cases, arguably the branch should be small enough to warrant only a single commit, so in these situations, I almost always rebase and squash commits into a single one, prior to merging into the target branch.

Gary Ewan Park
  • 17,610
  • 5
  • 42
  • 60
  • 1
    I second this: IMHO history is extremely valuable information. It can explain to a developer what happened and why. So preserve it as much as you can. – Csaba Toth Feb 05 '17 at 06:05
  • 47
    But the full history is visible on the develop branch, which is always going to remain. The master branch is a record of releases and so each commit should represent a squashed set of changes. – Glen Thomas Feb 21 '18 at 11:32
  • 4
    @GlenThomas If I need a hotix branch from master then I squash merge into master, how do I merge that commit into develop? If I squash commit master into dev won't I have problems? – Christian Rodriguez Jun 21 '19 at 07:23
  • 6
    Another reason to preserve history is because of the git bisect command. If you have one release that is good, and the next one has a bug in it, being able to go to the development branch and git bisect the series of changes is valuable. That command will walk you right onto the single fix that introduced the bug. Without history, you have to manually inspect all the changes as a group that went into the bad release. – DrChandra Nov 07 '19 at 22:41
  • 7
    @GlenThomas what exactly is the benefit of squashing? I mean, you'd use tags either ways on master, which would identify clearly the releases. – User May 16 '20 at 12:45
  • 3
    I second this as well. You should not do squash as it also caused problems for us. – Meeting Attender Oct 04 '21 at 19:58
46

The master branch is used to maintain a record of releases, so each commit should represent a squashed set of changes from the development branches that made up the release build.

Squashing the commits makes it much easier to see what changes went into a release and to create hotfix branches from a release commit when necessary. Tag each squashed commit with the release version number.

Glen Thomas
  • 10,190
  • 5
  • 33
  • 65
  • 19
    I like the idea, but how do you accomplish it in an elegant fashion? Meaning: if I attempt to just merge-squash the develop/release branches into master at different points in time, the new squashed commit/PR shares no common history with the previous squashed commit and results in merge conflicts. That can be mitigated by merging master back into develop after the squashed commit, but then the next develop->master merge-squash thinks that every commit you've ever made should be a line item in the commit message. – AbePralle Jun 18 '19 at 01:44
  • 4
    @AbePralle You should never squash merge the develop branch to master, create a release branch instead. I have stopped using GitFlow a long time ago so I can't remember the strategy exactly. I would strongly recommend getting rid of the develop branch and instead branching only from master. The reduced complexity will save you a lot of time. – Glen Thomas Jun 18 '19 at 10:59
  • 4
    Wouldn't the exact same problem @AbePralle highlighted happen with a "release" branch? The comment did not really address the problem, which seems to be a main concern to 8 people so far, and the other answers are arguing for opposite solutions. I feel elaboration/amendment is warranted for such a highly up voted answer. – Steven Jeuris Oct 01 '21 at 11:53
8

If you squash merge between develop, a release branch and master it gets very hard to merge a change to a release branch back to develop without file conflicts. It's also hard to merge a hotfix to develop, then merge develop through a release back to master later.

LukeN
  • 1,698
  • 15
  • 29
0

The original article is pretty explicit about using true merges. Given that your linked Atlassian article says nothing about squashes, I’m going to say that there is no existing precedence for this.

Moreover, using squash merges has absolutely no upsides in this kind of workflow, but has such severe downsides that it might be impractical.

  • develop and gang are eternal branches as well so you will save no space by squash-merging into master (except for that one less parent pointer on every master commit)
  • True merges (since they have parentage) makes finding out how master relates to develop straightforward. With a squash merge though the two histories becomes completely divorced. Then doubt starts to fester: did I really “squash merge” into master correctly? Or could it be out of synch. with develop?
  • You’re also going to need to merge hotfix and release branches into master… ugh
Guildenstern
  • 2,179
  • 1
  • 17
  • 39