Managing hotfixes when develop branch is very different from master?

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?

57068 次浏览
小开

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) 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.

小开

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.

小开

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-branches 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.

小开

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.

小开

All answers were smelly. My personal solution is mid releases.

Once every 3-7 days you do a microrelease

Like you name it 1.01, 1.02 an so on. Next release on customer will be 2.0 Those mid release must include only features that are stable (and thus not merged into master yet)

This allow you to keep master and develop consistent over time and do hotflix with light heart and avoid lot of troubles


提交答案