I'm trying to find the correct flow to manage this kind of development, where A and B are two independent features, and C is a third feature that relies on A and B.

An obvious approach would be to develop the three features in a sequential way, such as:


But I want to be able to push A and B for review while still working on C.
If I do branches for A and B, I'm not sure how to handle C :

 \--B--   ?-C

Is there a good canonical way of doing this?

  • Sharing your research helps everyone. Tell us what you've tried and why it didn't meet your needs. This demonstrates that you've taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat May 22 '20 at 17:32

If feature C depends on features A and B in the sense that both should be implemented, verified and correct for C to work correctly, then the canonical way is to delay development of C until the feature branches of both A and B have been merged back to develop (or master, depending on what your main development branch is) and only create the feature branch for C after that.

If for some reason the development of C can't wait that long, you should create the feature branch for C as if it didn't have the dependency on A and B and then regularly merge the changes made to the feature branches of A and B into the feature branch of C.


You seem to assume that developing a feature requires a feature branch. In this case, the canonical branching would look like:

  \ \--A--/ \       /
   \--B--/   \     / 

But what happens if after the merge, adjustments are required for A and B? What if furthermore these appear to be required for C? And what if all those features depends on some other code that evolves with impact on all the three? The longer the feature branching, the more painful it might get.

Let me now challenge your assumption: What if you gave up your feature branching for a continuous integration, e.g. like trunk based development?

Of course this is not hat you're asking for. But it has the advantage of putting dependency management where it belongs: not in git (the tool) but into the team (the people). The team could easily work together to understand the dependency and overcome it in a creative manner, for example:

  • Define common interfaces early - as soon as these are ready C could start, and with lower risks of rework
  • Start to develop a stub or a mock for A and B, on which C could lean on. Then everybody could concentrate on the independent parts.
  • 1
    "putting dependency management where it belongs: not in git (the tool) but into the team (the people)" Great point! I've heard lots of people say they have a git problem, but more often than not, it's actually a process problem. – Andrei Mustață May 27 '20 at 7:50

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.