How does one work on a new git branch that depends on another git branch that is not yet merged?

Question

Here's my scenario:

• My project is following the topic branching pattern.

• I create a branch to fix some problems, let's call this branch problem_fixes. I make my changes, and submit a pull request.

• I need to start work on a new feature, so I create a second branch called my_feature and commit a bunch of changes.

• At some point I realize my_feature is dependent on problem_fixes which has not yet been accepted and merged (the my_feature branch relies on some of the fixes from the first branch and I can't make progress without them).

Short of badgering my project lead to accept and merge my first branch faster, what is the best process to follow here?

I am wondering if I need to start a new, third branch based on problem_fixes (instead of master) and merge in my commits to my_feature? Or will it be okay if I simply merge problem_fixes into my_feature and continue work -- assuming problem_fixes is merged into master first, when my_feature is merged it should theoretically be okay(?)

Himelman

I think your question would fit much better on programmers.stackexchange.com – Ornas

@Theo: I don't think so. This question is about "software tools commonly used by programmers", as per the faq. – Saloop

meh, i hate stackexchange. fragmentation ftw. thanks for the pointer though i will check it out. (edit: categories on stackoverflow would have made me much happier than an affiliated group of separate sites) – Himelman

Because it's not a programming problem, it's a programming methodology problem. It's not a big deal, it will probably get a good answer here too, I just think it would fit better over on Programmers. – Ornas

Answer 1

Yes, I think you're on the right track. What I would do is create a new my_feature branch, perhaps work a little bit. When I realise that my_feature depends on problem_fixes, merge that branch in. This could happen right away if you know that you'll need it. Then, when my_feature is merged into master, you'll already have the changes you need.

Note that as long as you have a robust code review procedure, then if you try to merge my_feature into master before problem_fixes, then you will notice at that time.

Saloop

Answer 2

Create your topic branch off of the first branch. As soon as the first is merged into master you can rebase on top of that, and assuming not too much was changed it shouldn't be a problem.

If the commits of the first branch aren't changed your new branch will stack neatly on top of that, and if the commits are changed (squashed, edited or whatever) you can always do an interactive rebase of the second branch and edit it to look good once the first branch has been merged.

Ornas

Looks like I got two answers that appear to solve my problem. Greg answered first and with slightly more step-by-step instruction so marked as answer, but voted you up. If I could I'd give you +2 for forcing me to learn about rebasing -- it's a really important git concept. – Himelman

always go for rebase. merge commits are not helpful. – Fortitude

Answer 3

In a case where i've started working from master then realised after the fact that i need some changes from another branch that cannot be merged in because it still has some breaking stuff (but the stuff i need is complete) what i'd do in that case might be

• Merge their branch into mine

• Finish my feature

• Wait for the other developer to finish his feature

• They merge into master

• I cherry pick my commits expect for the merge commit into master

What do you guys think, might be a way out of a particularly painful situation though it involves messing around with cherry-picking which most people think is a pain in the ass like rebasing.

Gabby