Search code examples
gitgit-branchgit-flow

Git Flow Confusion On Release Branch

I am trying to understand one thing in git flow. Lets assume we have branch tree like this

Git Flow

In this scenario I merged my release branch by opening a PR to master and dev separately. I merged PRs with using

git merge --squash

command. At the end of merge, I have two different commit ids

master has D1234 dev has C4567

My confusion starts here. If master and dev don‘t have the same commit hashes, in the next PR to master from release branch I will see C4567 in the PR. I had to merge an empty commit with no diff. Where am I doing mistake? How can I get same HEAD for master and dev after merge?

SOLUTION : SQUASH MERGE IS NOT A MERGE

Solution

  • Your diagram is wrong. A squash merge is not a merge. It causes a new commit to appear out of thin air, with no record of how or why. If you do a squash merge to master and a squash merge to dev, master and dev are two totally independent commits, unrelated to each other and unrelated to the feature branch. So the arrows pointing from the end of the feature branch to the ends of master and dev are false and should be deleted.

    If you wanted there to be some sort of relationship between these things, at the very least use real merges. And do not take shortcuts. Do this the normal way: PR to dev, merge to dev, then see about getting that (the merge commit on dev) onto master.

    A release branch (which seems to be what you are asking about) is like a normal branch off of dev except (1) it stops all features from being merged into dev, and (2) as you rightly say, the goal here is to merge into master, though of course we must also merge back to dev. You might want to see the original document, https://nvie.com/posts/a-successful-git-branching-model/, which is much simpler and clearer than the atlassian page you cited.