When there are two feature branches that has some dependencies, and they are work in progress, but some piece of code want to be shared, why shouldn't I merge a feature into another?

  • 1
    Because neither feature has been stabilised to the point of being production worthy. If the other branch is rejected, fails, etc... then so does your branch. If you need common functionaility wait till it gets into production, or refactor it out into a third feature that can be merged in quicker than the other two longer lived branches.
    – Kain0_0
    Nov 4, 2020 at 4:39
  • 1
    Or, option, three, cherry-pick the commits related to that common functionality, if feasible.
    – Joe
    Nov 4, 2020 at 10:15

1 Answer 1


Merging two features

If you merge feature branch B into feature branch A, then A contains both the features of A and B. That's what merging is, after all.

This means that you no longer have two separate feature branches with individual lifecycles. When A gets merged into master, that also entails B's features (which are now in A) being merged into master.

Worse still, it's possible that when you merged B, B's feature was incomplete, and now you've merged a half-implemented B feature in master by merging A into the master.

To be fair, merging B into A can be acceptable, if and only if these features themselves are now intended to share a single life cycle. If you intend to work on the merged AB feature, instead of on A and B separately, then merging A and B is actually okay.

Mini master branch for shared feature logic

If you intend to keep the feature branches separate even though they share some logic, there's a better way of doing it.

  • First, you branch off the master (let's call it A), in which you develop the share logic.
  • Then, you branch off of A into specific feature branches (A1 and A2), and develop them separately.
  • If it turns out that the shared logic needs to be fixed/adjusted, then you commit changes to A, and then merge A back into A1 and A2.
  • When A1 and A2 are done, you merge them back into A, resolving any conflicts.
  • When that is done, you can merge A back into the actual master.

In this scenario, branch A acts as a "mini master" branch that coordinates the shared logic between its sub (feature) branches.

Keeping it simple

Does the above approach seem like a lot of juggling? Yes it does. It's viable, but it takes some careful planning and consideration. It's usually better to divide the tasks so that the two features can be developed fully independently, as this makes things notably easier to manage.

When A and B depend on the same (partial) feature, it's usually a lot easier to first develop A, merge it back into master, and only then branch B off from the master. This means that your shared logic is already in the master when you branch.

Alternatively, you could branch A off of the master, then branch B off of A, and when A and B are done, merge B into A before merging A into the master. This means that, as far as the master branch is concerned, you are merging "AB" into the master using a single commit. They are not separate features at this point.

In cases where you must develop A and B concurrently (e.g. due to a deadline), you're going to have to handle them as if they're one big feature. This means either:

  • Having a single AB branch that contains both features (which is what you would've ended up with if you merged A into B, the way your question suggests)
  • Having a single AB branch that has further sub-branches for A and B individually (as I suggesting in the previous chapter)

I will generally advise the second option as it keeps things clear (at the cost of some branch juggling), unless the A and B features are very small and can easily cohabitate in a single branch.

Some diagrams

I whipped up some diagrams to help explain it. You'll notice that in all acceptable cases, every branch always merges back into the branch they originally branched from. This keeps things neat.

What you suggested, which is not advisable. The problem is that after merging from B to A, what was now the A branch has become the AB branch. Any further development to B is always going to cause issues. Therefore, your merge has broken the branching strategy.

enter image description here

Using a "mini master" branch for the shared logic:

enter image description here

Doing A and B sequentially:

enter image description here

Branching B from A:

enter image description here

  • Why "Any further development to B is always going to cause issues"? What kind of issues? I think about modifying some file_from_B in branch A (after merge), and then modifying same file in branch B... is that kind of issue?
    – abarazal
    Nov 5, 2020 at 18:46
  • @abarazal: Any change you make to B (after the merge to A) will not be part of A (unless you do another merge from B to A, at which point my argument repeats itself). A will still contain "old B", while B will contain "new B". So when you merge the B and the A branches into the master (regardless of which order you do it in), that's going to create merge conflicts or simply broken code.
    – Flater
    Nov 5, 2020 at 22:22
  • @abarazal: Copy/pasting your file changes between branches is the antithesis of good versioning, on top of repetitive work and prone to error/forgetfulness.
    – Flater
    Nov 5, 2020 at 22:23
  • Ok, I undestand that it's not a good practice. But just to clarify, it may not neccesary lead into merge conflicts, right?
    – abarazal
    Nov 5, 2020 at 23:12
  • @flater the need for a mini-master may not be apparent at the beginning. So the start may be more like your first diagram, with A and B branching perhaps from different master commits. A merge to an AB (perhaps itself branched recently from master) is an opportunity to check and resolve conflicts prior to the merge back to master. Further feature changes (discouraged) could take place on the relevant A/B feature branch, before being re-merged to AB and then to master. Possible to make changes on AB itself, but that should be conflicts only really. Mar 25, 2021 at 14:12

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.