Frage

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 ..

War es hilfreich?

Lösung

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.

Andere Tipps

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.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top