After merge of release branch, why is master 1 commit ahead of develop?

Question

I am still new to this so I am trying to understand why master ends up 1 commit ahead of develop instead of the same after merging a release branch back into develop and master.

My develop branch was 5 commits ahead of master, then I created a release branch and tagged which was also 5 commits ahead of master, then I merged release branch back into develop and master but master ends up 1 commit ahead of develop.

Is this because no changes were made to the release branch and it was the same as develop so the merge didn't create a commit on develop but it did on master which makes master 1 commit ahead even though master and develop now are the same at this point?

Is this ok? Will this cause any problems?

Anhydrite

Answer 1

The issue is that the merge commit is being detected. Your commit history probably looks something like this:

*------------------ A [master]
 \                 /
  *---*---*---*---B [develop,release]

Commit B is, as you mention, 5 commits ahead of master. When you merged the release branch back into master, this created a merge commit, A. That merge commit does not yet exist in develop.

This is not something that you need to worry about, because the merge commit doesn't contain any changes itself, it only merges the two histories together. Normally, that commit will automatically end up in develop next time you finish a hotfix branch anyway.

Athapaskan

Wouldn't it be better to just merge master back into develop instead of release? – Lederman

@Bas: Not sure what you mean by the latter part of your comment (release was merged into master, not develop). There isn't really any need to merge master back into develop, because the only thing that develop is missing is the merge commit (but develop already has all the changes contained in the merge commit). – Athapaskan

Why is a hotfix branch useful in this scenario? – Lettered

@jmng: What do you mean? I didn't say it was useful, just noted that the merge commit will end up in develop eventually since the OP is using git-flow. – Athapaskan

You mentioned that "Normally, that commit will automatically end up in develop next time you finish a hotfix branch.", I had the same question as the OP ("what about that extra merge commit on master and not on develop") so I was confused when you mentioned a hotfix in order for the merge commit to end up in develop; why is the hotfix needed/related? – Lettered

@jmng: I've edited my answer to clarify a bit. It doesn't matter that there is (temporarily) a commit in master that isn't in develop, because the commit doesn't contain any changes other than merging the two histories. git-flow is set up to have both master and develop be long-running branches, so while functionally develop will be ahead of master, it's okay for master to have an extra commit. – Athapaskan

@jmng: To answer your direct question, a hotfix is based off master, and merges into both master and develop. So when the hotfix is completed, its history, including the last merge commit, will now be in develop. – Athapaskan

OK, now I understand, thanks for clarifying :) If I may ask: if nothing happens to justify an hotfix, is there a standard/safer way of assuring that the merge commit is propagated to develop, to avoid the difference between master and develop? I'm actually afraid to try this on Eclipse/egit and end up with the usual rejected-non-fast-forward mess :P – Lettered

@jmng: Aside from a hotfix, you could just merge master into develop. But there is really no need, because while the commits differ, the contents of master and develop are both the same since the release branch started at develop and was merged into master already. – Athapaskan

No guarantee you would ever do a hotfix, we have a repo who's master is 2,300+ commits ahead of develop. There should be a setting to omit these commits from the difference (if there is I'd love to know). Unless develop is a copy of master these branches will always be at least 1 commit different in their history. In 2023 I still actively dislike this feature. – Shortchange

I take it back, it's a feature of the merge type we're doing. I'm no longer put out by it :D #56753467 – Shortchange

Answer 2

IMO that 1 commit ahead is compared to origin/master or the remote branch your master is tracking. Since you have do a merge on local branch, it will create a new commit for that merge on your local master, therefore makes it 1 commit ahead.

Chuu

I just always thought that development should be ahead of Master at all times? – Anhydrite

When I merged the release to master and develop I only see a commit to master, is this because there were no changes to the release after it was made and was at the same point as develop? I agree with your statement the commit is done to the local master and pushed to origin, even on the remote branches develop is now 1 commit behind master. I normally don't create release and feature branches as I am a solo developer, I have just been merging develop into master on the remote server. I would like to change that practice though because it seems wrong to do. – Anhydrite

1.It is normal. 2. I still think ahead/behind is talking about local branch vs remote branch.. so N/A. 3.Yes for the question. And for the best practice part honestly I don't know. – Chuu

Answer 3

Now you have to Fast-Foward develop into master to have master and develop in the same level

Hegira

While a fast-forward merge of master into develop would technically solve the "problem", it is unnecessary (see my answer), and is not recommended by the standard git-flow branching model. – Athapaskan