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(?)
So merging one branch into another has a secondary effect: it moves the merge base of those two branches. In particular, the new merge base of the two branches is now the second parent of the merge commit.
Your reasoning is correct. To answer your question, nothing happens to branchB when branchA gets merged, only the diff would change to master . ... "or only branchB", which if merged before branchA would effectively merge branchA changes as well.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With