undefined | Better HN

0 pointsconor_f26d ago0 comments

This is a perfect example that I've often seen in practice. There's nothing blocking in this workflow at all, and no reason these changes cannot be made in independent changes. e.g.

1) API implementation - Including tests and docs this should be perfectly acceptable to merge and review independently 2) UX implementation - Feature flagged, dummy API responses, easy to merge + review 3) One quick "glue" PR where the feature can be integration tested etc

This prevents awful merge conflicts, multiple rounds of increasingly complex stacked reviews, and a host of other annoyances.

Is there any reason that the stacked PR workflow is better that I'm ignoring or overlooking?

0 comments

gpm26d ago

You're creating more work for no reason. There is absolutely no reason to make dummy API responses, a feature flag (well unless you want to delay public release of the features - domain dependent here), or a glue PR.

Moreover you haven't even eliminated the dependency. The UI PR requires knowing that the dummy API responses you've created fit the right format - i.e. approval of the API PR up to small nits.

Just test against the actual implementation from the start. Even without stacked PRs just leave the second as a draft with both sets of commits until the first is merged then rebase and make it.

Stacked PRs are superior here because they eliminate that extra work of the draft PR and parallelize the review process slightly better.