Re: Merge conflicts with version numbers in release branches

From: Enrico Weigelt <enrico.weigelt@vnc.biz>
Date: May 29, 2013, 09:09 UTC
Message-ID: <1346886189.4154.1369818548437.JavaMail.root@vnc.biz>
In-Reply-To: <201304071749.10912.thomas@koch.ro>

Thomas Koch wrote:

Show 5 quoted lines

> 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.