Rebase in Hotfix Workflow

[tsschaffert]

I have a question regarding the rebase step in the hotfix workflow ("rebase master to production"):

Would this not cause problems, if the master branch contains commits that are not yet released to the production branch? For example, if since the last release (=update of production), a new feature was finished and merged to master, and then a hotfix on production is needed.

As far as I understand it, this would rewrite the commits on master, causing conflicts for everyone who checked out the master branch with the new feature or created a new feature branch based on the master branch.

[aleksijohansson]

I think in such a case the feature branches could also be rebased to master before trying to merge

[tharna]

Yes, the feature branches should be kept up to date with master, or atleast rebased before the pr.
Master branch itself shouldn't be a problem as there shouldn't be any local changes into that when you do a pull, so even if it's rebased upstream it doesn't cause conflicts.

The rebase part is probably not the most optimal and clearest way to do this, but the value of keeping history clear outweights that. With the tooling (git-flow.sh style cli tool) this can be made more streamlined with automating the feature branch rebasing for example.