I'm following the gitflow branching model. I follow the guidelines quite closely.

• I create a release branch from dev, and make final bugfixes and adjustments there
• I then merge this into main, and then into dev, and then delete the release branch
• I use the --no-ff (no fast-forward) flag when merging my release branch into both main and dev
• the only thing that I currently don't follow is tagging my main from git after incorporating the changes from release into it. Instead I tag it from the GitHub repo using the releases feature.

However, my dev branch now says this:

This branch is 1 commit ahead, 1 commit behind main.

I'm confused by this. It appears that the new merge commit (caused by merging release into dev and main) on each branch is the only difference. Is this supposed to happen? Am I doing something wrong?

CodePudding user response：

This is completely fine, and expected in certain situations. Let's walk through what happened:

1. You created branch release from the tip of develop. At this moment develop and release are identical.
2. You add some commits with bug fixes to release (or not, it doesn't actually change the outcome for the purposes of this question).
3. Once you're happy with release, you deploy it and merge it into main using the --no-ff (no fast-forward) flag. This creates a new merge commit on main. So at this moment release and main have identical contents, but main has one extra commit on it.
4. Now you also merge release back down into develop, also using --no-ff. This creates a new commit on develop that isn't on release or main.
5. Now you delete release.

So at this point, develop has at least 1 commit on it that isn't on main, and main has exactly one commit on it that isn't in develop. Presumably you didn't add any commits to develop since creating the release branch, and therefore develop would be exactly 1 commit ahead of main, and exactly 1 commit behind main.

Note: the next time you do a release branch the same process will occur, but you will end up with 2 commits on main that aren't in develop, and this will continue incrementing until you do your first hotfix branch, which will bring all of those older merge commits back into develop all in one shot. This is expected, but can be confusing the first time you see it.

Tip: After experiencing the hotfix branch bringing many merge commits back into develop, now when I work in repos that use Git Flow, after merging release into main, I prefer to merge main into develop rather than release into develop. The contents will be identical, but now develop won't be behind main anymore. This also has the added advantage of making it easier to determine if any release branch is fully up to date with main before you deploy it; you simply need to make sure the commit master points to is also in release.