How to merge a release branch back to master

Question

We have two major branches:

• master Updated by developers
• release Updated by CI. Developers don't push to this branch.

Our automated Continuous Integration works like this:

1. CI takes the latest version of the release branch
2. builds a systems
3. integrates the latest code from the master branch (without push)
4. runs all tests
5. if all tests are good: The version number gets updated and the release branch gets updated.

This has one problem:

The version number in the master does not get incremented.

If we would do this, there would be an endless loop, since CI thinks:

ah, new changes on the master (it does not see that it is only the version number update). Let's test the code ....

How to get the changes from CI back to the master?

We want to avoid a merge where all CI commits get into the master. On often updated repos there would be a CI commit daily. The result would be that there are too many CI commits in the git history. With "too many" I mean "too many" for the human eyes.

Update

We do "continuous integration". Twice a day the software gets tested. If it is stable the version number gets increased. There are no "release day" in our context.

We have development/feature branches. But I think this is not a part of the question. Merging into the master gets done by a developer. This is not automated.

Answer 1

Sounds like you want to continuously integrate changes coming from developers, in which case you should use the same branch ( master ), the CI system should simply lay a label on the master branch and use that (or pick the latest CI label laid by some other method) to do its work - all it does is verification of the integration branch at that label, it shouldn't normally do any commit on the codebase itself.

Using another branch just to implement CI is IMHO a convoluted way which will only bring you complications and trouble (like this very question, for example).

If indeed you want to use the release branch for a release you should never blindly pour in it changes from master . And you should never merge it back into master either since master now evolves into the next release . - the context of the 2 branches diverges, just because a change works in one branch doesn't mean it'll work in the other.

The release branch should have a gradually smaller rate of commits while nearing the release date (much smaller than the commit rate in master ). If fixes for issues seen in both master and release are desired they should be cherry-picked and double-committed to the 2 branches with the verifications appropriate for each branch.

Answer 2

Well... how about switching strategies?

Work in development/feature branches, merge into master, ci releases master (or tags if you like).

For git the master is the official history of the project, branches exist only to contribute to the master.

I currently know of two (ok three with linux) different mainstream procedures working with git. One is the github model , the other one is Gitflow model. Gitflow is a little bit more complicated, and also often not necessary.

Why invent a custom strategy when there are already two existing working solutions?