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

It's just two ordinary merge commands:

git checkout master
git merge hotfix
git checkout develop
git merge hotfix

You can think of the "normal" flow of commits being from your development branch to master as the work is completed. In a back-merge, the commits are flowing in the opposite direction, from hotfix into your development branch.

Answer 2

Backmerge is nothing but add your hotfix changes into your current working branch.

Let's say you have two branches Develop and Master
You found any major bug on Master. You fixed it on Master branch itself as a hotfix. Later you need to add your bugfix change into your current working branch i.e Develop branch. so you need to do back-merge like this

---

1. git checkout Develop
2. git merge Master
3. git push origin Develop

Answer 3

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.