Is expected to have one pull request per feature for big features?

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?

I’d recommend the first (one PR from feature to dev branch) or third (multiple merges into feature branch, then merge that) approach. I agree that the second one sounds messy, except maybe for components/changes that actually make sense independent of the feature you’re working on.

Whether splitting makes sense depends a lot on your specific situation, both the extent of changes and how comfortable the people in charge of reviews are with big changes.

One thing I’d recommend is getting the reviewers on board early, especially if you go with the “one big PR” approach. As a reviewer I’d rather see a draft where I can get a rough idea (and comment on design flaws, if any) and then watch it get more refined than have a big chunk of code dropped in front of me. Draft PRs work well for that.