CODEWITHSUNDEEP
git
sara lance
sara lance

Reputation: 603

Recommended git workflow

I would like to make a pull request per feature. But I'm having problem with the workflow.

For example, I worked on a feature in branch feature1, made a pull request and while I wait for that pull request to be approve I want to start working on another feature.

In feature2 I would like to have the code from feature1, what is the best approach for this?

I used to make another branch from feature1, but then when I make a pull request of feature2 to master I have all the changes from feature1 and feature2.

How people do this?

Upvotes: 0

Views: 110

Answers (4)

Christian Fosli
Christian Fosli

Reputation: 1847

I think the best approach is not to do so.

As long as there is some other featureX which does not require code from feature1, I would start with featureX instead of feature2.

During code review there might be change-requests which affect the code you need for feature2.

If waiting for feature1 to be merged is not realistic, (review will take too long and there are no other features to start with), then feature2 can be branched out of feature1. However, if feature1 is squashed into master you'll need to do some rebasing, or branch out of master again and cherry-pick the work specific to feature2 from the original feature2 branch into the new feature2 branch.

Upvotes: 1

eftshift0
eftshift0

Reputation: 30212

Just to add a little more on what has already been said: feature2 can be on top of feature1, the only thing is that you have to be careful when moving the branch around so not to automatically include stuff from feature1..... this is so because there might be different situations that can make it break if you are not careful. For example: Feature1 gets to be merged..... but squashed. Then the revisions that feature2 is on aren't valid anymore.... same thing if feature1 is rebased..... or reworked completely.... in all those cases you will have to be careful to not include the revisions from feature1 when you move feature2 around.

The easiest way to handle this is by rebasing feature2 but only what really makes it up:

git rebase --onto anywhere feature2~4 feature2

That is assuming feature2 is made up of 4 straight revisions. So, all in all, it's ok.... just be careful.

Upvotes: 1

matt
matt

Reputation: 535140

In feature2 I would like to have the code from feature1

You can’t. The "code from feature1" is the very code on which you are awaiting approval! If you are permitted to incorporate unapproved changes into another new branch, then what is the point of a PR and the whole approval process? You might as well be working alone and skip PR altogether.

Features, in your architecture, need to be independent. Conversely, if they are not independent, then you should not have submitted a PR prematurely; this should all have been one long branch.

Upvotes: 0

Tim Biegeleisen
Tim Biegeleisen

Reputation: 521239

In fact, branching from feature1 to start feature2 is probably the best idea. So ideally you should enforce that feature1 gets merged first, before feature2. If you categorically can't enforce this order, then it might imply that you should have started work on feature2 before feature1, that is, you should have switched the branches.

Upvotes: 1

Related Questions