> You should never be going off and work on huge changes without keeping in sync with the base branch.
I agree, but the stacked PR approach doesn't preclude this. If you periodically `autorebase` the stack against `origin/master` right after a `git fetch origin`, your stack stays in sync with `master`.
> ate a longer lived branch and make small PRs to that. Then merge longer lived branch into master
Large features don't necessarily imply long-running feature branches, though. I personally prefer feature flags (or some other mechanism for conditional execution) on the base branch for features that are "open" for more than a week or so, say.
"Large" is also subjective. You could have changes that are large in terms of lines of code added, the number of services that are being touched, or the number of different+unrelated concerns involved.
As an example, this week I worked on a semi-greenfield Kafka service. Stacking PRs helped me keep track of the review process a lot more easily than "one big PR" would allow, and the stack was merged in 4-ish days. I structured the stack like this:
- Add a `proto` file covering messages that this Kafka consumer reads off the incoming topic
- Pull in a gradle library for protobuf code generation
- Add in a simple Kafka consumer and producer
- Add a `Processor` that works on incoming messages
- Hook everything up; the sevice consumes off Kafka, "processes" the data, and produces back to Kafka
These PRs aren't similar in terms of size or complexity, but the various concerns that comprise this service are nicely split up.
> Stacked PRs make all this more difficult.
I'm in agreement. Stacked PRs involve more overhead, but there are times when this is a reasonable tradeoff.
> You should never be going off and work on huge changes without keeping in sync with the base branch.
I agree, but the stacked PR approach doesn't preclude this. If you periodically `autorebase` the stack against `origin/master` right after a `git fetch origin`, your stack stays in sync with `master`.
> ate a longer lived branch and make small PRs to that. Then merge longer lived branch into master
Large features don't necessarily imply long-running feature branches, though. I personally prefer feature flags (or some other mechanism for conditional execution) on the base branch for features that are "open" for more than a week or so, say.
"Large" is also subjective. You could have changes that are large in terms of lines of code added, the number of services that are being touched, or the number of different+unrelated concerns involved.
As an example, this week I worked on a semi-greenfield Kafka service. Stacking PRs helped me keep track of the review process a lot more easily than "one big PR" would allow, and the stack was merged in 4-ish days. I structured the stack like this:
These PRs aren't similar in terms of size or complexity, but the various concerns that comprise this service are nicely split up.> Stacked PRs make all this more difficult.
I'm in agreement. Stacked PRs involve more overhead, but there are times when this is a reasonable tradeoff.