0

I am struggling with a merge from branch "hotfix" into "master" at a specific "position" or commit while the master branch was constantly changes

The "hotfix" branch is of course a hotfix and need to be tracked from the master for later purposes.

How do you provide this?

Example 

A - B - C - D / master
    |
     \ 
      \_ hotfix containing commits E - F - G

the "master" branch should become

A - B - E - F - G - C - D / master

Is there any chance to achieve this by avoiding merge conflict?

PS: The goal is to NOT have another branch called e.g. "hotfixes/hotfix-123".

Ole K
  • 754
  • 1
  • 9
  • 32
  • 1
    Using `git rebase` you can achieve result `A-B-C-D-E'-F'-G'`. But if there are any conflicts "somewhere" between commit `D` and `G`, they need to be resolved. Reordering (putting `E-F-G` before `C-D`) doesn't solve the issue. – kolejnik Nov 03 '17 at 17:28
  • 1
    See [What are the practical consequences of rewriting GIT history?](https://stackoverflow.com/a/1491022/211627) – JDB Nov 03 '17 at 18:00
  • @JDB well noted and already aware of – Ole K Nov 03 '17 at 18:08

1 Answers1

2

Edit: updated to match additional information given in comments below Edit 2: add tagging recommendations

Goal: merge hotfix into version 1.0

First, let's rephrase your original picture.

A---B---C---D // master
     \
      E---F---G // hotfix

Assuming this is how history currently looks

      C---D // master (2.0)
     /
A---B  // current version 1.0
     \
      E---F---G // hotfix

I'd recommend creating a branch to track version 1

git checkout -b release/v1 <B's commit SHA>

And create a tag to mark what has actually been shipped

git tag v1.0.0

Then merge the hotfix into this new branch

git merge hotfix

And create a tag to mark the new version and release that to where ever it's needed

git tag v1.0.1

Your history will now look like this

      C---D // master (2.0)
     /
A---B  // tag v1.0.0
     \
      E---F---G  // branch release/v1 and tag v1.0.1

Finally, it sounds like you don't need the hotfix changes in version 2.0, but if you do:

git checkout master
git merge hotfix

Original answer

It's not possible to "merge" the hotfix branch into master and get the history to look the way you want. However, it is possible if you're willing to rewrite the master branch. Warning: this will cause major pain for anyone else working off of the master branch and should be avoided.

Given

A---B---C---D // master
     \
      E---F---G // hotfix

You can get the desired history with

git checkout master
git rebase hotfix/foo

This will result in

A---B---E---F---G---C'---D' // master
     \
      C---D // original master
Graham
  • 13,165
  • 2
  • 16
  • 14
  • What is `foo` in `hotfix/foo` ? –  Nov 03 '17 at 18:05
  • reason why i need it: the HEAD of master is already version 2.0 with major changes. but the hotfix is for version 1.0 where several files are completely different – Ole K Nov 03 '17 at 18:06
  • Note to OP - the original hotfix branch is still there, but all commits in it became part of the new master. –  Nov 03 '17 at 18:07
  • @Arkadly foo i assume is one of possible several other hotfixes (so /hotfix can be used as category, kind of) – Ole K Nov 03 '17 at 18:07
  • @Graham42 lets assume `git rebase` causes a conflict. would this not cause ALL the following commits after `G` to get resolved until HEAD is reached? – Ole K Nov 03 '17 at 18:24
  • @OleK updated answer based on your comment about 1.0 and 2.0 – Graham Nov 03 '17 at 18:50
  • I already use `release/` and have the "release/1.0" available in the repo - Do you recommend to hotfix into a new version branch (E.g. release/1.0.1) or simply merge it into the same ( release/1.0 )? – Ole K Nov 03 '17 at 19:13
  • I'd recommend tagging every version you ship with an exact version number using `git tag`. I've updated the answer with tagging recommendations – Graham Nov 03 '17 at 19:49