Git 合并发布分支因小版本更改而发生冲突

Question

For a project, say I have some release branches:

release/1.2
release/1.1
release/1.0

These release branches are based on the minor version. Because they keep being supported, each of them will be at a different patch version, stored somewhere in some build configuration file (gradle in my case). For example:

release/1.2
  build.gradle contains "version 1.2.1"
release/1.1
  build.gradle contains "version 1.1.4"
release/1.0
  build.gradle contains "version 1.0.7"

Now, suppose I fix a bug in branch release/1.0 . Then I'd like to merge this branch to the next two, to propagate the fix. In general, this would work quite smoothly.

However, when fixing the bug in release/1.0 I would also want to bump its patch version, from 1.0.7 to 1.0.8, changing the file build.gradle to contain "version 1.0.8". But if I do that, the merge into the next release branches will create a conflict on that file.

Obviously there must be a better way to support my initial intentions. What are the best practices in this case?

One way I could think of is to not store the full version in a file, but only use git tags, and then have gradle (or any other build tool) obtain the full version from the git tag. One major disadvantage of this approach is that the build would fail on a sourcebase that is exported from git.

Answer 1

Two possible solutions come to mind:

Cherry-picking

I have found that instead of merging, git cherry-pick works a lot better. With merging, you're running into the issue you are describing, and the version number might only be one instance of this. As the branches diverge further, you will find other conflicts that will not be easy to resolve. Since merging will always try to merge from the point where the branches were created, in many cases, far too many changes are pulled in.

With cherry-picking, you can migrate individual commits from one branch to another one. This works a lot better, since you can pick and choose which parts you want to migrate.

git cherry-pick 1234567

This will take the commit identified by the mentioned hash (it can be on any branch, in your case on release/1.0 ) and apply the commit on your current branch. It will just include the changes from this one commit, nothing else.

For me, this works a lot better than merging between support branches, since I can just take the parts that I want to fix, and does not include any other changes from previous or unrelated commits.

Git Attributes

If cherry-picking is not what you're looking for, you can use Git Attributes to define a merge-strategy for a specific file or a set of files.

See here for more details.

It lets you define an attribute like the following, where for the database.xml file, always our side is used when merging, disallowing any incoming changes during a merge for this file:

database.xml merge=ours

You would define the above in a .gitattributes file in your repo.

In your case, you would probably use something like

build.gradle merge=ours