Reputation: 979
How can I create the new branch to be inclusive of the pending pull request, while not creating issues when I come to push the new PR? For example, I don't want changes from the first PR creating conflicts when I merge the second.
Considered branching from the first feature branch or merging the first feature into the second branch, but not sure which is the better option.
Upvotes: 6
Views: 2700
Reputation: 12938
Given that
There's absolutely no possibility of merge conflicts between PR1 & PR2.
And if
Your approach is perfectly ok & won't affect history too.
In case PR1 get changed and that is a dependent for PR2, addition to your work, you might need to adhere that change in your PR2 implementation (Ex: a dependent method signature). If this is the case, rebasing your current branch(PR2) taking master (or develop, the main development branch into which PR1 has been merged) branch as the base would make your history much nicer. :))
Upvotes: -1
Reputation: 12381
Well, the changes on the second pull request depend on those from the first one. So if (when) you end up changing the first commit, the second one will naturally be affected. This is the whole point of a pull request and why you don't push the code directly to the main repo.
With that said, create your feature branch from the first feature branch and set it as upstream:
git branch --set-upstream-to=[your remote]/[first feature branch]
This way, you keep only the unique, newer commits in the particular feature branch. Running git status
will then show changes compared to the other feature branch instead of comparing against master.
Every time the first feature branch is changed -- during the time before the PR is approved and it is actually merged -- you run git pull --rebase
to apply any changes from feature branch one to feature branch two.
Upvotes: 3