Re: Merge conflicts with version numbers in release branches

[Enrico Weigelt <enrico.weigelt@vnc.biz>]

Thomas Koch wrote:

> it's a common problem[1,2,3] in Maven (Java) projects and probably in other
> environments too: You have the version number of your project written in the
> pom.xml. When one merges changes upwards from the maint branche to master,
> the
> version numbers in maint and master are different and cause a merge conflict.

My advice: dont merge directly, but rebase to latest master. Maybe even rebase
incrementally (eg. "git rebase master~100 && git rebase master~99 && ...).
This heavily reduces the chance of conflicts that need to be resolved manually.

I'm a big fan of topic branches. For example, we have some bug #1234 in
the maintenance release. Fork off at latest maint, lets call the branch
1234_somewhat. Now do your bugfixing, testing, etc. When thats done, rebase
on latest maint (in case maint moved further) and merge it into maint.
Now rebase the 1234_somewhat branch onto master, do tests etc and finally
merge into it. (note: all merges here will be fast-forward, IOW: pure 
append operations).

Of course, all of this wont make the conflicts on the version number change
go away magically, but at least it will be more clear while resolving it.
If you always do the version number changes in some separate commit, which
has some specially formatted message (eg. 'Release: 1.2.4') you could 
hack some some little filter-branch magic, which automatically kicks off
these commits before rebasing.