Managing hotfixes when develop branch is very different from master?

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 develgit 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 mastergit cherry-pick HOTFIX_HASH

Now, the commit is present in master and devel. To get around this, type

git checkout develgit rebase master

and the commit will disappear from devel since it's already present in master.

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.

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.