-2

Let me first tell you about the requirements of our software releases: We need to release a new version of our software 2-3 times per year. A new release contains new features. After a new version is released, this release needs to be maintained for quite a long time (let's say a few years) in case there is a bug that needs to be fixed. If such a bug occurs, it usually needs to be fixed in several of these releases. However, new features should NOT be ported to these releases.

Currently, we use bzr as our VCS and we're not happy about it: It is buggy, slow, not supported by popular build servers and uses A LOT of disk space (since every branch uses its own directory).

So we decided that we want to switch to git. We planned the following branching model: master is where every new feature goes in (via feature branches). Whenever a new release is needed, a new branch (e.g. release30) is created and given to QA for testing. These release branches will never be merged back into master and not into each other. But Bugfixes from master need to be applied to these branches. Cherry-picking these bugfixes was tested and fulfills this need.

However, my boss has the following (very reasonable imo) requirement for the new VCS: For a specific change, he wants to quickly and easily check in which release branches this change was applied and in which it was not, so he can quickly tell the customer whether this specific bugfix is included in this customer's release. Preferably with one click in a GUI.

With cherry-picking, this is difficult. I came up with the following idea: Cherry-picking will be done with cherry-pick -x, adding the hash of the cherry-picked commit to the commit messages. The change can then be searched via git log --all --oneline --decorate --grep=<SHA-Hash>. Of course, this requires usage of the command line. Aliases could be used to shorten the commands.

Questions: 1. Is there an easier solution to this problem than the one I posted above? 2. Is there a GUI available on Linux that supports such a feature? 3. In this situation (Multiple long-living release branches), how do you keep track of which change is included where?

Cerbrus
  • 70,800
  • 18
  • 132
  • 147
mave117
  • 21
  • 1
  • 2

2 Answers2

0

Have you considered "A+successful+Git+branching+model"

Philip Oakley
  • 13,333
  • 9
  • 48
  • 71
  • We have. But the model presented by Mr Driessen does not satisfy our needs. We need several "master" branches in that model. – mave117 Jan 17 '17 at 07:23
  • @mave117 Sounds like a management naming problem, along the lines of "a rose by any other name..". Arguably (*) with a DVCS there should be no 'master', as we have perfect duplication. Veracity is proven by the sha1 of one's local artefact, c.f. `old master` https://news.artnet.com/art-world/how-do-experts-arrive-at-an-opinion-about-artwork-authenticity-323652. – Philip Oakley Jan 17 '17 at 10:50
0

I found the answer to this problem in the git book by Preissel & Stachmann (don't know whether it is available in English).

The idea: After the migration, we merge every release branch with the preceding release branch: git merge -s ours release/20 on the branch release/21. This way, these branches are merged without introducing any of the changes from release/20.

Then, if there is a bugfix on release/20 that needs to be included in release/21, it's a simple git merge release/20 on the branch release/21. If there are conflicts, they should be minor and manageble.

The tracking is now fairly simple: The question "Is bugfix X in release Y?" is equivalent to "Is the bugfix introduced with commit X a predecessor of the commit that branch Y points to?". This question is fairly easy to answer both in a GUI and the command line.

mave117
  • 21
  • 1
  • 2