0

We have almost settled for a branching model where we have a master branch which represents the production code and a release-x.x branch that represents future releases.

However, there are a few scenarios we are unsure how to solve effectively:

Live bug fix is not relevant for the current release

  1. A new feature is branched of the release-2.0 and does a complete re-write of module A.

  2. The new feature is completed and merged in release-2.0.

  3. A bug in the current live module A is found and fixed on master.

At this point we figured there are 2 possible scenarios:

  1. We rebase release-2.0 on master to bring bug fixes and fix conflicts (discarding the bug fix code which is now irrelevant). Eventually we then merge release-2.0 in master when the release is ready.

  2. We cherry-pick only the bug fixes that are relevant to the release into release-2.0 and when the release is ready we override the entire master history with the release-2.0 history.

Solution #1 forces us to resolve merge conflicts with commits we know aren't needed, but solution #2 forces us to wipe the entire master branch and replace it by the release-2.0 branch's history on every release. That introduces a slight chance of losing bug fixes we forgot to cherry-pick on release-2.0 and could also break ongoing bug fixes that were branched of master before the release.

A feature doesn't make it into the release afterall

  1. We create a new feature, rebase on release-2.0 and merge it into release-2.0 with --no-ff.
  2. A few bugs are found so we fix them on feature and redo the above merge process.
  3. Clients review the feature once again a decides they wants to change many things -- the feature has no value without these things, but we cannot make these changes for the release-2.0 and will have to wait until release-3.0.

What is the proper way to deal with that scenario? Should we revert all commits related to the feature that were done in release-2.0 with a message such as "Revert feature X - pushed back to 3.0" and then later merge feature to release-3.0?

plalx
  • 42,889
  • 6
  • 74
  • 90
  • It seems like there are multiple questions here, both of which are primarily matters of opinion. Is it possible to narrow the focus of the question and rephrase it as a technical issue? – larsks Aug 03 '17 at 21:52
  • @plalx have you get the answer to solve your questions? If yes, you can mark it as answer. And it will benefit others who have similar questions. – Marina Liu Aug 17 '17 at 05:52

2 Answers2

0

First, if you changed module A both in release-2.0 and master branch, and you want to apply the changes of module A on master to your release-2.0 branch.

Except the solution1 and solution2 you listed, there is another way that you can only apply changes of module A from master to release-2.0. That is checkout the related file(s) from master to release-2.0 directly and then commit changes. Detail steps as below:

git checkout release-2.0
git checkout master /path/to/moduleA  
# Such as git checkout master moduleA/*
# Now module A is what you changed in master
git commit

Second, for most cases, if you use the version format as x.y (major.minor), x (major) stands for the main/significant changes required by clients, and y (minor) means we fix bugs or clients need little changes when they review the work you did.

So if your clients make requests for big changes when they review the version of 2.0, you can develop the project as version 3.0. After finishing works, your client will review the version of 3.0. If they report bugs or tiny changes for the version of 3.0, you can changes the version as 3.1 (rename your release-3.0 branch as release-3.1 or add tag 3.1 after you finish changes).

Besides, there is another different branching module you can refer: works on develop branch -> when finish the work -> merge develop into release branch -> after the release branch is approved/reviewed -> merge release into master branch -> record the release version in tag.

Marina Liu
  • 36,876
  • 5
  • 61
  • 74
0

I would suggest using tags instead of branches to represent what is in production. This way you could simply checkout a new hotfix branch and fix your bug, then deploy this commit directly and tag it as the current production code, no need to merge it back if you know that everything will change the next release.

* 54c82e0 - (HEAD -> master) Commit6
* bb6db8e - Commit5 
* 5156c9f - Commit4 
| * 630a150 - (tag: v1.1) Hotfix commit 
|/
* db5c984 - (tag: v1.0) Commit3 
* 00c6c5c - Commit2 
* 715412a - Commit1

You would use the branching model that you have planed, but master will instead be a your "trunk", where all your work is merged to, while the current production code will always have a tag, that you can checkout from if you need hotfixes.

I would be careful with choosing a "proven" branching model like GitFlow blindly, so I think you are on the right track, trying to find out what suits your needs. For more reading see:

sp1nakr
  • 378
  • 2
  • 12
  • Well l'm actually trying to achieve trunk-based development, not GitFlow ;) – plalx Aug 17 '17 at 06:07
  • Sounds good! Though, release branches is in no way needed if you try to achieve a more fluid branching model. Trunkbased pretty much removes all excess branches, the exception being feature branches used for pull requests and code review etc. – sp1nakr Aug 18 '17 at 07:02
  • Well in my case we need short-lived release branches only to prepare the release itself (e.g. we could have to remove some features that are in master but should only get deployed in a future release somehow -- things like that). – plalx Aug 18 '17 at 14:49