Mike Strauch wrote:
> We have a
> maintenance branch in which the majority of commits are bug fixes. We
> would then like to merge those bug fixes into our master branch. The
> difference being that there will occasionally be a commit in our
> maintenance branch that we do not want to merge into our master branch
> because it contains application version information
I see. Yes, this is interesting (and not covered by gitworkflows though
it should be).
> 1. We fix some bugs in the maint branch (previous bug fixes)
> 2. We test those fixes
> 3. Merge the fixes back into master (M1)
> 4. Commit version information to maint branch (version info commit)
> 5. Release from maint branch (v1.0)
> 6. Start the process over from step 1 but with the version information
> commit in the maint branch commit history.
>
> So, in this scenario there is really only ever 1 commit that we don't
> want to be merged into master from the maint branch.
Now your "merge -s ours" solution is looking like a good one. So the
workflow on the release day might look like this:
1. Fix some bugs on maint
2. Test them
3. Merge fixes back into master
4. Version info commit on the maint branch
5. Test a little more, tag the release.
6. "merge -s ours" from maint to master
7. Do some other work on topic branches and master.
8. Push.
Ideally, in the published history, maint would _always_ be an ancestor
of master. Life is simpler that way.
> This is not
> always the case of course. There could be some other commits in maint
> branch that we don't want to merge back into master.
Sure. Another possibility is to explicitly revert patches from maint,
either as a separate commit or as part of a merge. The latter would
generally not make sense unless it is a very small patch.
For example:
1. Fix some bugs on maint.
2. Notice a test on maint is passing now. Mark it as such.
3. ... more work on maint ...
4. Switch to master. Merge from maint. Since the test is
failing:
i. "git reset --keep HEAD^" (undo the merge)
ii. "git merge --no-commit maint"
iii. Mark the test as expected to fail.
iv. "git commit", mentioning the test failure in the log message.
This is called an "evil merge" because it introduces changes that
are not from either side. Used judiciously it can be useful for
ensuring that every commit passes some basic tests (which might be
wanted if you use "git bisect" heavily).
"git revert" is simpler, of course.
Hope that helps.
Jonathan
--
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