What's the correct Git flow to develop on two independent features + one feature that relies on both?

Question

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:

----A----B----C

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 :

----A--
 \--B--   ?-C

Is there a good canonical way of doing this?

Answer 1

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.

Answer 2

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

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

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.