4

I am not quite sure, how to name my problem. But I will start with how I usually used git.

I am working as a single developer on one git repository. Usually I make feature-branches from master, and merge them back into master, when the feature is finished. When meanwhile another feature-branch was merged into master, I rebase the other branch on master, before merging.

That worked very good, until recently. One dependency I have in my project, needs an update. But it was not yet decided how this update will be implemented. But I can simulate the new behavior quite simply.

So I branched from master, and simulated that fix. So when the actual fix is available and merged into master, all changes above can be rebased back on master. But the decision on that fix is still pending, and my branches are stacking up:

* ee8d0ab (HEAD, featureTwo) * e659932 * 27986c0 (featureOne) * f0011e6 * d4187cf * 552e35a * 37d597f (simulatedFix) * e0eb3d0 (origin/master, master) * b06583c * d295b3e

I feel, that this is not good. It feels like I am building up dept. Imagine how this would look at featureTen, or featureTwenty.

What are the possible drawbacks of this method? And what is the best way, to handle this situation?

Improve this question
1
  • If someone has a better title, please feel free to edit! Commented Apr 7, 2014 at 10:01

1 Answer 1

Reset to default
5

Create a new development branch - let's call it "dev-with-dep". That branch will be rebased against master, and all the feature branches that depend on the new dependency will be rebased against dev-with-dep and merged into it when they're done.

The dependency update branch itself will be rebased against dev-with-dep(after dev-with-dep is rebased against master, ofcourse) and merged into it whenever you reach a state you want to rebase into the other feature branches.

Once the dependency can be merged back to master you do it via dev-with-dep(which contains all the features that you finished) the other feature branches will again be rebased against master.

That way you don't get a stack of finished feature branches that wait for the dependency - they all await neatly in dev-with-dep. Also, since features that depend on the dependency update are merged into dev-with-dep when they are done, you can resolve merge conflicts between them as early as you merge one. That means that if feature A is merged and feature B isn't:

  • If both A and B don't depend on the new dependency - A is merged into master and B rebases and solves the conflict.
  • If both A and B depend on the new dependency - A is merged into dev-with-dep and B rebases and solves the conflict.
  • If A doesn't depend on the new dependency but B does - A is merged into master, dev-with-dep is rebased against master, and B rebase againt dev-with-dep and solves the conflict.
  • If A depends on the new dependency but B doesn't - nothing you can do here, as A is merged into dev-with-dep which B can not yet access.

Still - I can't think of any method that allows you to solve that last case early, so my solution remains "optimal".

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.