Stephen Bash <bash@xxxxxxxxxxx> writes: > In my office we've recently run into three separate fixes required on > our maintenance branch that should not be included in master (our normal > workflow is to make changes on maint, tag, release, and then merge to > master). Normally these "maint only" fixes are interspersed with > commits that should go back into master. In the past the "maint only" > commits were rare, so I'd carefully use "merge -s ours" to avoid > including the "maint only" changes in master. But now I'm wondering if > there's a better process/workflow? I wonder what these "maint only" changes are, and the most importantly, if you know if a change you are about to commit is "maint only" material at the time you make it, or if it is something you would notice retroactively only when it is time to prepare merging maint back to master. Assuming the former, you can use exactly the same discipline you already use to keep your 'maint' free of commits you make on 'master' to add new features that shouldn't be in the maintenance track. Let's think how you are already achieving that. First you examine the change you will make, and decide if it is only meant for master or it should go to both maint and master. If the change is meant to go to both maint and master, you would queue to a branch that can be merged to both maint and master. The simplest workflow to do so is to commit the change directly on maint, later to be merged to master along with other commits on maint. Or you may choose to fork a topic branch from maint (or an earlier point on maint) and commit the change on that branch. You would merge the topic branch to 'maint' and then later either merge the whole 'maint' to 'master', or merge the topic branch to 'master'. Alternatively, you may even choose to first merge the topic branch 'master' to make sure it does fix what you wanted to fix and then merge that topic to 'maint' later. On the other hand, if a change is only meant for 'master', you either commit directly on 'master' or commit on a topic branch that can be merged to 'master' and merge it later to 'master'. But you never merge that change to 'maint'. That means you would not merge the topic branch (if you used one) to 'maint', and you would not merge 'master' to 'maint. How would you apply the same discipline for "maint only" situation? First you examine if the change should only go to 'maint', and if so, you will queue it to a branch that can only be merged to 'maint'. If a change should go both to 'maint' and 'master', you will queue it to a branch that can be merged to both. Notice that the latter "branch that can be merged to both" can _NOT_ be 'maint', as your 'maint' is contaminated with commits that should not go to 'master'. So the first thing to realize is that you no longer are allowing yourself to merge 'maint' as a whole to 'master', nor a branch that is forked from 'maint' to 'master'. What follows that observation and discipline are: - You would keep for-both-maint-and-master, maint, and master branches. - You treat the for-both-maint-and-master branch the way maint branch in projects like git itself is treated, i.e. everything can go to master. Commit changes that are meant for both maint and master on this branch, either by committing directly on it, or forking a topic from a commit on that branch and committing on top of it. - You merge for-both-maint-and-master into maint and master at appropriate times. - You never merge maint to master, nor merge master to maint. - You commit changes that should only go to master on master, either by committing directly on it, or forking a topic from a commit on that branch and committing on top of it. - You commit changes that should only go to maint on maint, either by committing directly on it, or forking a topic from a commit on that branch and committing on top of it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html