How to make pull requests if they are dependent from each other?

Viewed 234

I should implement a really big feature that will contain hundreds of changes.

If I would create one feature branch for that from develop, reviewers will reject my pull request, because it is too big (no one will check hundreds of changes).

So, I decided to split pull requests. I created feature branch called my-big-feature from develop, where I will have my whole feature implemented.
Then I created another subfeature from my-big-feature, worked on it and gonna make PR to my-big-feature.
Then I should continue to work on subfeature2 that is dependent on subfeature. But my subfeature is not merged yet.
That's why I created subfeature2 from subfeature, worked on it and decided to make PR to subfeature.

But it has own disadvantages. When reviewers review my subfeature and find some mistakes, I should constantly merge subfeature to subfeature2 again and again.

I think it is not efficient. So, what should I do?

1 Answers

Aim for the Simple Case

Explain to your team, what you are going to do. Then move forward step wise and get one commit after another into the code base. Provide tests.

Think about 'Branching'

Branching is not necessarily a git problem. Sometimes it is more effective to branch within code, e.g. by providing an on-off-switch for the new feature. This gives you the freedom to develop the feature in small steps until it is ready for the public. This will result in many small commits being merged into mainline regularly. As soon as the feature is ready you can remove the switch and delete the old code branch.

Code Branching Strategies

If it is not possible to provide single commits without breaking existing behavior, then you may want to think about advanced techniques like Feature Toggles or Branch By Abstraction.

These techniques must be accepted and understood within the team, since they will increase the complexity of the code base temporarily.

Following them will however provide a valid strategy to get tested code into production soon. It will also help you to rollout/distribute new versions of your software in a controlled manner.

Related