0

i'm trying to find a solution for a git/github related problem i couldn't find anywhere else.

First, some assumptions:

Your team uses 2 branches, development and release (release here is just master). There's the hotfix-* branch too.

Your team uses Github.

Any pull request needs to be reviewed by another teammate, including hotfixes.

And now suppose you found a bug that needs to be merged in release asap.

What i want to know is if there's a "best" way of dealing with hotfix branches. I know 3 different ways of working with hotfix branches. Let's say you create the hotfix branch based off of release. Fix the bug, create the commit. Then:

  1. Push to remote and create a pull request to release. Then you can either immediately re-open a pull request from hotfix to development, or rebase hotfix from development and then open a pull request to development.

  2. Push to remote and create pull request to release. Merge pull request, then immediately create a pull request from release to development. This keeps development updated with hotfix commits merged in master, but created a bunch of merge commits in both branches when we want to merge development back into master.

  3. Push to remote and create pull request to release. After the merge, rebase development from release. Then force push development.

Every one of these has at least 1 downside:

  1. Since the merges look different, github creates different merge commits in release and development, even though the hotfix commits are the same. Then when we want to merge development into release there's a bunch of repeated commits.

  2. When merging release into development, something similar to the previous case happens. The merge commits look different and we end up with a bunch of repeated merge commits that don't look very clean

  3. This way of working is the cleanest in my opinion, but it requires a lot of coordination from the dev team since the rebase changes the history of a shared branch. I'd need to tell the other devs that they need to fetch and rebase their origin development branch every time a hotfix is merged.

All gitflow hotfix blogs i've seen assume you do the merges locally. But i've seen none that explains what's the correct way of working with hotfix branches in this particular (but i think very common) scenario.

Ramon Echeverria
  • 1
  • 1
  • See [git merge branching for hotfixes](https://stackoverflow.com/q/59959413/1256452) for my take on this. Whether you merge locally or via github is not relevant to the overall strategy (though for conflict resolution issues, it is relevant). – torek Aug 01 '22 at 10:01
  • in this case, since there's only 2 branches, and the release branch where the bug lives, will always have the shortest graph, does it has any benefit to fix the bug at the commit it was introduced? – Ramon Echeverria Aug 01 '22 at 14:34
  • Probably not—but eventually you'll have more than the two branches, if your company and software exist long enough... – torek Aug 01 '22 at 14:37

0 Answers0