Question

Our project is split into 4 different Git-Projects (hierarchy), where the leaf project is the customer part.

To release a new version, we are using (SourceTree) and the GitFlow-Feature. So, a new branch out of the latest dev branch is created, and when finishing the release, it will be merged back to dev, and populated to master-branch.

For easier developing, we used to use a fixed version ("dev" insetead of x.y.z) for all projects, while working on the development branch and set the actual versions, whenever we populate the branch to the release-branch.

So, we want to avoid the merging back of the pom-file to the dev-branch. (The versions defined in the pom should stick with dev while all other (final) changes should be merged back to dev.)

Is there a way to achieve this without reinventing the wheel?

So, upon finish a release:

  • populate all changes to master branch
  • merge changes back to development branch EXCEPT pom file?
Was it helpful?

Solution

Make the change to the version in the pom file its own commit in the release branch and immediately "fake" merge it back to the development branch (merge --strategy=ours).

https://stackoverflow.com/a/19794987/11296

Once that commit is merged (even fake merged) back into the development, its change won't be included in future merges back into development (until the pom file is changed again).

Note, if you have any commits on the release branch before the version-change commit, make sure you "real" merge those first, and then fake merge the version-change commit (and then real merge the future real changes, then fake the future version changes, rinse-and-repeat ...).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top