The disadvantage of stacked pull requests

Code review is a significant process to secure and maintainable code, and it's helpful to share knowledge of the business domain. Some developers claim that it's important to make a pull request small enough to let reviews easily understand the source code. I think it's a good habit because this stance implies that pull request authors should communicate with reviews smoothly.

There are several ways to make a pull request small; one of them is stacked pull requests. Stacked pull requests are also known as incremental pull requests. This is a technique to avoid a large pull request by splitting it into small pull requests and chaining them in order. It means most stacked pull requests branch off from branches of other pull requests instead of the default branch (it's usually main).

Of course, stacked pull requests make it possible to have small pull requests, but there are also disadvantages. I want to explain about them.

Stacked pull requests will be eventually merged into a large pull request

Stacked pull requests will be combined into a big pull request, and you will have to resolve conflicts before merging it to the default branch because other members may have already merged their pull requests into the default branch. Even without any conflicts, the diff between the "stacked pull request" and the default branch would be enormous. Are you really confident to merge it into main? Of course, stacked pull requests have been reviewed, so the "stacked pull request" seems to be fine. However, while you are stacking pull requests, the main branch will grow simultaneously. This means that the environment on your repository has changed since you reviewed all stacked pull requests. I recommend you should review the "stacked pull request" just before merging, but I know it's too large to review entire the "stacked pull request."

For members who are not relevant to the stacked pull requests, it's difficult to understand each stacked pull request

If many developers are involved in your repository, it's difficult for those who are not relevant to the stacked pull requests to understand each stacked pull request because they don't know the context of the stacked pull requests. Stacked pull requests are chained by the consequent pull requests. If a member fails to follow one chain of stacked pull requests, it would be challenging to keep up with them.

Trunk-based development

I believe trunk-based development is the best way to make pull requests small. There is only a stacked branch: the default branch (main). Keep opening pull requests from main, and merge them. However, there's still a catch with trunk-based development. Small pull requests are causing problems to understand the whole purpose of your goal. If you have to merge 100 pull requests into main for a new feature, it might be difficult to understand what is the purpose of each pull request. The advantages of large, long-running pull requests tells about it. I agree with the article somewhat, but I'm sticking with the idea of chopping a big diff as small pull requests as possible to make code review faster. Perhaps, each pull request should have the whole story in its description.