Reputation: 955
A Git scenario:
Now I want to create a branch for another feature - F2. F2 relies on F1 and also relies on some new additions to develop made by other developers.
In other words I want to create branch F2 that has F1 and the latest from develop.
What is the / an appropriate workflow for this?
Upvotes: 3
Views: 177
Reputation: 1773
Start F2
on top of F1
and merge in the additions from origin/develop
. Once the pull request for F1
has been accepted, rebase F2
on top of the new origin/develop
and submit a pull request for F2
.
Upvotes: 0
Reputation: 124648
Create your new branch from F1
and merge develop
into it, or create from develop
and merge F1
into it. The end result is the same in terms of content, just the revision tree will have a different shape, which shouldn't really matter.
When F2
is ready, create a pull request. But only after F1
was already accepted. If you create a PR for F2
before F1
is accepted, you will inconvenience the reviewer, as in that case F2
and F1
will both be in that PR.
Reviewing pull requests is all about reviewing the diff between the source branch and the target branch. If F1
was accepted already, then only the unique changes in F2
will show up in the diff. It doesn't matter how many other branches have been merged into F2
, as long as they have already been merged into the target, they won't show up in the diff, so the reviewer can concentrate on the unique changes of F2
.
While working on F2
, if there is a change in F1
, you can merge that if you need it. It doesn't really matter. After F1
is accepted into the target, the reviewer will only see the unique changes of F2
, it won't matter how many times it merged from F1
, and it doesn't have to contain the entire F1
.
Upvotes: 1