5

I our team we use a gitflow approach to maintain our codebase. But there is one case in which we struggle.

We are in the following case, we have two feature branches (feat/A, feat/B) that were create from develop. feat/A is now finished, so we merge it into develop, well this feature now lives in develop, it is waiting to be tested to be merge into master.

And now, there is an emergency to put feat/B into master because it is very important ( a communication error, a client expected it to be already present, whatever .. ). In this case feat/B is not 100% finished ( this is why it is not merge into develop for now ) but the current version is stable and ready to be used.

So how would you deal with that ?

We can't count on gitflow since it will say to do the following:

  • Merge feat/B into develop
  • Merge develop into master ( I don't mention release/X but the principle is the same )

But .. remember, develop contains feat A which is not ready to be thrown in prod. So we can't merge develop into master at all.

The solution I have is the following:

  • Merge feat/B into develop
  • Merge feat/B into master

So, this way master doesn't contains feat A. This solution works, but don't seems to be a scalable practice in large project ( dozens of developers working on a same repo ). Now we are 3-4 dev so we can quickly communicate with each other, but in a large team it is not really possible ..

  • 1
    Don't use feature branching. Use trunk development with feature toggling. – Euphoric Dec 15 '17 at 13:18
  • @Euphoric this doesn't work when a feature is in fact the modification of an old feature which breaks retro compatibility. – Nathan Vasse Dec 15 '17 at 13:26
  • Have both features with toggle. New users have new feature. Old users have old feature with ability to switch when able. – Euphoric Dec 15 '17 at 14:05
  • there is an emergency to put feat/B into master because it is very important ( a communication error, a client expected it to be already present - I think you already answered your own question. IMO this kind of emergencies usually cause development processes to open an exception in order to solve the customer's problem. – Emerson Cardoso Dec 15 '17 at 16:09
5

In the gitflow model this situation would be considered a hotfix, where the prescription is exactly the solution you proposed, assuming the merge doesn't pull in other changes from develop that aren't ready for master. If the merge would pull in unwanted changes, you'll have to rebase feat/B onto master first.

  • Yes, you also answered the next question I have in mind by saying "If the merge would pull in unwanted changes, you'll have to rebase feat/B onto master first.". Thank you. – Nathan Vasse Dec 16 '17 at 14:01
1

I recommend treating this as a hotfix. Rebase feat/B off master and later cherry pick changes back to develop or merge master into develop.

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.