What is a back-merge

Question

I’ve watched some videos on the git-flow scripts and one term that comes up is “back merge” - e.g. hotfix is merged into master and back merged into develop.

I’m assumin

Answer 1

The use of the term "back merge" is usually somewhat arbitrary.

It just means to do a merge, like any other, but in a direction that is "backwards" compared to the normal flow of the branching conventions. If you visualize branches arranged like

master    hotfix    release    dev    feature
  |          |         |        |         |
  |          |         |        |         |
  |          |         |        |         |
  |          |         |        |         |

then changes normally "flow" from right to left - feature to dev to release to master. But while hotfixes are pretty far left - they get created from master - they still have to be merged "to the right" into dev, so some people describe that as merging backwards, or back-merging.

In my opinion, that's not the most compelling use of the term, because it can be read to imply that the opposite merge (from dev to a hotfix branch) were a "forward merge" - but in fact that's something that shouldn't be done. In this case the direction being "backward" is more about the general flow of changes if you visualize the branches in a particular way as above.

A more compelling use of the term is when you have a long-lived feature branch (which itself is something of an anti-pattern in agile processes that are likely to use gitflow; but sometimes you may need one). In that case you periodically should update your long-lived feature from dev, so that the two don't deviate too much leading to a disaster of a merge conflict later. (And this opens up a whole can of worms about "unnecessary" merges, what makes a good history, and git rerere... but I digress.) That can clearly be called a back-merge because the opposite - merging your feature in to dev - is a normal, textbook use of merge in the branch model.