Managing hotfixes when develop branch is very different from master?
GitGit FlowGit Problem Overview
I'm using the "Git Flow" branching model, with a master branch and a develop branch. I'm working on a major new release, so my develop branch is wildly different from my master branch. This creates a problem anytime I need to make a hotfix on the master branch and merge it back into develop. There are almost always conflicts, and it's becoming a real pain.
What is the best way to manage this? It would be easier for me to make the small hotfix changes on develop manually and then merge everything into master when I'm ready without merging master back into develop. Is this possible?
Git Solutions
Solution 1 - Git
The simplest way to get some commits from one branch to another is cherry-picking.
Assuming that your fix in master
has the commit hash HASH
and you want to take that hotfix into your devel
branch, do a git checkout devel
followed by a git cherry-pick HASH
. That's it.
If you want to take all changes from master
into devel
, you can achieve that with
git checkout devel
git rebase master
If you have the opposite scenario (you make a hotfix during development in a devel
branch and want to take that fix into master
before devel
gets fully merged into master
), the workflow is quite similar. Assuming that the hotfix has the hash HOTFIX_HASH
, do this:
git checkout master
git cherry-pick HOTFIX_HASH
Now, the commit is present in master
and devel
. To get around this, type
git checkout devel
git rebase master
and the commit will disappear from devel
since it's already present in master
.
Solution 2 - Git
My general workflow for this situation is to create a bug-fix
branch of master
that fixes the problem. Once it's ready, merge that back into master
then merge master
into develop
.
This assumes that your bug fix is almost a one-to-one between the code it needs to change in both branches. If that's the case, you could always try a git merge -s ours master
(see [man-page][man-page]) into develop
so the develop
branch takes priority.
I use a similar process for managing bug fix releases on an open-source project I'm working on. master
is always ahead of where the bug fix needs to be applied, so I create a branch from the tag that needs the fix, apply the fix and release, then retag and merge the new tag into master
. This causes a conflict because of the version numbers, but can be avoided with the command above.
Hope that helps.
[1]: http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html "git mergetool
"
[man-page]: http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_merge_strategies
Solution 3 - Git
I usually follow this guide which fits quite well in most cases and avoids mayor of issues with conflicts and big changes.
If you could work on feature
branches and merge them in development
only prior to a release
branch creation (meaning you are actually preparing a release)... this method should avoid most of the merge conflicts you experience.
Since breaking changes would occur at a feature-breaking
branch, you MAY only have conflicts once at the time this feature-breaking
branch gets merged into development. And you could as well merge development
into the release
branch at any time to keep it updated.
You will also be cool with merging into development
all the hotfix-branch
es you have with minimum or non conflicts at all.
The guide I shared on the link before makes big emphasis on never merging from development
to master
or backwards. Always handle your releases via a release
branch.
Solution 4 - Git
This all depends on how you are going to use GIT to manage your code, your release plan, and your version. The best practise is to have master
branch to hold your production level code, have develop
branch to do your development, have release
branch branched out from develop
to handle your upcoming releases and hotfix
branch branched from master
to handle urgent fixes for production code. So the release
and hotfix
branches will finally to be merged back to BOTH master
and develop
to make sure both branches have the changes and later on when develop
branches out new release
this new release has no problem to merge on master
. And the tagging will be always on master
.
With this approach, the release
and hotfix
branches will be merged twice and the conflict is sometimes seen when merging to develop
, which is inevitable if there are many development activities going on develop
. Shorten your release
or hotfix
branch lifecycle could be a way to mitigate this problem. If conflict happens, solve it with whatever techniques and make sure don't change the completed and tested release
or hotfix
code.