Maint-only commits

Hi all-

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?  Certainly a well crafted alias or custom command makes the user's life easier, but still clutters master with "extra" merges.

Any thoughts?  Thanks!

Stephen

Stephen Bash <bash@genarts.com> writes:

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.

----- Original Message -----

The three recent cases have all been fixes that, due to refactoring on master, require different changes on the two branches (these specific changes have been non-conflicting in a merge sense, but incorrect in a code sense).  All three cases were known ahead of time as "maint only", but unfortunately the first one still snuck through the merge process and had to be reverted on master.

... <snip> ...

That's certainly a valid approach.  I discussed it around the office and got push back on adding additional complexity to our branching model.  So I'll document the "our" merge approach and perhaps revisit the branching model at the beginning of the next development cycle.

Thanks, Stephen

On Tue, May 17, 2011 at 10:20 AM, Stephen Bash <bash@genarts.com> wrote:

At @work we use something like this. We have three branches:

- trunk (aka master, but it started as a git-svn branch long ago...)
- release
- maint

Our maint merges to both trunk and release, via an automated process except when a conflict requires human intervention.

Occasionally someone will put something on trunk by accident that should've gone to maint. We revert it from trunk, cherry-pick to maint, and let it merge back down.

(Aside, I've found hudson^wjenkins to be great for misc jobs like this and prefer it to cron these days for non-sytem-related periodic events.)

j.

* Stephen Bash <bash@genarts.com> wrote:

Of course, there is: use topic branches and rebase.

Assuming you've found a bug in maint, which is also still in master.

#1: for off a topic branch (for that bug) from maint
#2: fix the bug there
#3: rebase to latest maint (if changed meanwhile) and test carefully
#4: (ff-)merge your bugfix branch to maint
#5: rebase bugfix branch to master (maybe incremental, if they
    went too far away from another) and test carefully
#6: (ff-)merge bugfix branch to master
#7: drop that topic branch, as you're done now.

cu