I used to use a merge workflow and my current team works with a rebase workflow.
In it, features branches are forked from the master, then rebased with the master and then squash merged onto the master.
I would like to keep a branch for minor changes onto the master that I could easily fit in the feature branches, though, I am unsure about what is the solution that will bring me less problems:
- fork minor_changes from the master and then merge it onto my feature branches (potentially many of them), and later squash merge the feature branches onto the master.
- fork minor_changes from the master and then rebase the - potentially many - feature branches with minor_changes, and later squash merge the feature branches onto the master.
I do not know if the first option will cause me any trouble, and I suspect that the 2nd one might duplicate commits in the final history.
Which is the best way to take care of this?
minor_changes
branch frommaster
.master
rebaseminor_changes
branch on tomaster
. You could set it up to track themaster
branch withgit branch -u origin/master minor_changes
then simply rungit pull --rebase
to keep it updated.minor_changes
branch.