> This implies the need for smaller pull requests maybe?

This makes me feel like perhaps pull requests shouldn't always pull/merge the changes directly, but instead there should be something like the GitLab "Start a review" functionality, where you can queue up code comments, before submitting all of them at once, but for pull requests.

As a Jira analogy, imagine the totality of the changes that you want to merge as an issue, but the individual steps/smaller requests as sub-tasks. The entire task would only be considered done after all of the sub-tasks are done, similarly, the changes should only be merged after all of the sub-requests have been successfully reviewed. Thus, development could happen more iteratively, with feedback sooner.

Otherwise you end up with something like the following being separate requests:

- FEATURE-123 add data models for the feature
- FEATURE-123 add service logic for the feature
- FEATURE-123 add logging and validations for the feature
- FEATURE-123 add unit tests for the feature
- FEATURE-123 add REST endpoints for the feature
- FEATURE-123 add front end code to forms
- FEATURE-123 add front end logic to use the REST endpoints
- FEATURE-123 add integration tests for headless browser

You don't actually want these changes to end up in the main branch before they are done. Alone, they provide no actual value and could only confuse people. Furthermore, if there are changes that are needed to the data model after it has already been merged, then you'd also need to do those within a later merge request, or one in the middle, which would just pollute the history and serve as spam, instead of being able to add more commits to the other sub request.

To me, all of this seems like a problem that stems from developers viewing code review as something to only be done at the moment when you want to merge the feature to your main branch. Even the tooling that we use is built with this in mind. It feels like there are better alternatives.

EDIT: So, you'd need something like the following:

- (WIP, 3/8 reviewed) FEATURE-123 add new feature // feature-123 branch, cannot be merged into main yet, review the below first
- (reviewed) add data models for the feature // feature-123-data-models branch, will be merged into previous
- (reviewed) add service logic for the feature // feature-123-service-logic branch, will be merged into previous
- (reviewed) add logging and validations for the feature // feature-123-logging-and-validations branch, will be merged into previous
- (in review, 9/13 comments resolved) add unit tests // feature-123-unit-tests branch, will be merged into previous
- (registered) add REST endpoints for the feature // feature-123-rest-endpoints branch, will be merged into previous
- (registered) add front end code to forms // feature-123-front-end-code branch, will be merged into previous
- (registered) add front end logic to use the REST endpoints // feature-123-front-end-rest branch, will be merged into previous
- (registered) add integration tests for headless browser // feature-123-integration-tests branch, will be merged into previous

(personally i think merges make the most sense, but some people prefer rebasing; it's just an example)

You can technically do the above already, by having a main feature branch and functionality specific feature branches all of which get merged into the main feature branch, before then being merged into the main branch after the feature is complete. It's just that people usually live with the view of: "One merge request == one feature", which i don't really think should be the case.