What to do with a big pull request for just one feature?

Question

We are using git flow as a branching model, and we have a feature ticket that conceptually is a pretty small feature in the software management tool, in this case Jira.

The thing is that the code on the feature seems to be big enough to have it all in one PR, and we can't divide the ticket in the software management tool as the feature is small enough to keep dividing it and maintain the sense of it.

In order to solve this, imagine that I have the develop, and feature/my_feature branches, then we could think of these different solutions:

The first option is to create just one PR from feature/my_feature to develop branch. That would end on a single big PR with a lot of changes. This is the root of the problem we want to solve.

The second option is to create multiple PRs from feature/my_feature branch to develop branch. However, that doesn't make much sense in all cases. You could have different components that make sense to have them independently in develop branch, but there are others that are linked to the feature, and having them without all the feature in develop wouldn't make sense or give value. It would just confuse other developers on why does it exist. Also, what about if at the end, the feature changes and you don't need it anymore, you will add more complexity.

The third option is to create multiple sub-features branches and create multiple PRs from them to the feature/my_feature branch. This sounds nice, but it will end on more local and remote branches (that are going to be deleted after merging them, but it's something to consider anyway), and it inevitably adds a little more complexity to the branch's management.

Is there another option that we are missing? Which one is the suggested one in gitflow? Or it does depend on the team and there is no preferred option?

Answer 1

All of the options could work. Some need some minor adjustments. Others are making tradeoffs.

The first option is to create just one PR from feature/my_feature to develop branch. That would end on a single big PR with a lot of changes. This is the root of the problem we want to solve.

This could be a viable option, depending on how big the final change ends up being. I'm not sure how reliable the numbers are, but it appears that the maximum recommended size for a code review is about 400-500 lines of code. However, it would be best if there was some kind of rationale to the commits. Before opening the PR, the commits on the branch can be rewritten and revised to be a logical, sequential set of changes. Rebasing can be used to achieve this, which would let a reviewer not only see the changes as a whole, but walk through the commits to learn the story behind the development of the feature.

The second option is to create multiple PRs from feature/my_feature branch to develop branch. However, that doesn't make much sense in all cases. You could have different components that make sense to have them independently in develop branch, but there are others that are linked to the feature, and having them without all the feature in develop wouldn't make sense or give value. It would just confuse other developers on why does it exist. Also, what about if at the end, the feature changes and you don't need it anymore, you will add more complexity.

If there's anything that can be split out of my_feature and delivered into develop earlier, this could be an option. Perhaps there are some parts of the code that can be refactored and those commits reviewed placed into develop first. There may also be some technical enablement changes to enable my_feature without affecting other things in develop.

Alternatively, the use of feature flags can allow you to put smaller changes into develop earlier and review each change. You may be able to even go as far as testing these changes. An example could be making back-end and API changes behind a feature flag, but enabling that feature flag in a testing environment to allow interacting with the API.

The use of keystone interfaces could also hide some of the implemented functionality until you put the right interface in face to unblock it.

The third option is to create multiple sub-features branches and create multiple PRs from them to the feature/my_feature branch. This sounds nice, but it will end on more local and remote branches (that are going to be deleted after merging them, but it's something to consider anyway), and it inevitably adds a little more complexity to the branch's management.

This seems like a good idea, to me. The overhead of additional branches seems worth it for the ability to review and understand the discrete changes.