Menu
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 assuming back merge is a concept and not a native git command. What exact commands comprise a back merge operation?
877
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.
In case you are using the Tower Git client, undoing a merge is really simple: just press CMD+Z afterwards and Tower will undo the merge for you!
But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch. The major benefit of rebasing is that you get a much cleaner project history. First, it eliminates the unnecessary merge commits required by git merge .
Related Content. A merger in which the target company merges with and into the buyer, the buyer assumes all of the target company's assets, rights, and liabilities, and the target company ceases to exist as a separate entity.
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.
170
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
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
