I did a lot of reading on popular git workflows including A Successful Git Branching Model, merging, rebasing, and cherry-picking, but I'm still not able to apply all this on how to solve the problem described below. I feel like cherry-picking might help here, but I'm not sure if that's the best idea.

Let's say I have three devs working on three features in branches f1, f2, f3, and these get merged into a development branch, creating 3 commits one on top of the other. The changes go through customer UAT, and the customer decides f1 and f3 are good to go live, but f2 needs some work.

How could I achieve this? What are some good-practice ways in which I can have f1 and f3 go live in the current release, but f2 can go in the next release?



Your problem goes a bit beyond the normal git workflows and can be handled in several ways.

If the problem found during UAT is really small and can be fixed "while the customer is waiting", then you could do a quick bugfix followed by a new UAT of f2 and a release of all three features.

If the problem is more substantial, you could revert the merge of f2 into develop, do a regression test to check that nothing broke and then release the remaining features.

If comments from the customer during UAT are expected to be rather common, then it would be a good idea to consider doing a (pre-)UAT with the customer before the feature is actually merged into develop. Then you can work out the kinks out of the feature before it can affect the release schedule of other features.
If multiple features-under-development are expected to influence each other, you could also create temporary branches in which these features are integrated with each other for doing a test on both of them.

| improve this answer | |

I don't think there is a technical solution to this problem. I have had similar scenarios in the past and trying to solve this technically (by having separate branches) is cumbersome at best, and hell at worst.

If the decision which features actually make it into your final release is made that late in the development process you should think about some other way of integrating them into the final product. Well actually you should think about educating the customer that doing all this upfront development work just to defer the actual rollout is a bad idea in itself - but I know how difficult this can get.

One example (which is not the solution in every case) is to have the code merged into the development branch regularly (using the model from "A Successful Git Branching Model") but having a feature toggle in place that decides whether or not the feature is actually active and visible during runtime.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.