GitHub, you serve us well, but please allow me a tiny complaint about the rebase flow.
First, some context.
In a trunk-based, linear history rebase development workflow (aka tl;dr), we do primarily smallish PRs. The project has two active developers, and we consistently accomplish a handful of PRs daily. The review takes priority. Usually, an initial review is ready, and related fixes are implemented in less than an hour. Unfortunately, our CI is slow, and we typically don't have its status available once the human part of the review is complete.
GH has added the auto-merge (or auto-rebase) feature. It presumably works best in merge flows and is only nearly as good for the linear history rebase workflow. Unfortunately, we can't set multiple PRs to auto-rebase and expect GitHub to handle it automagically. Our branch protection rules require that source branches must be up-to-date before rebasing to main. Once any PR is rebased, the following ones are not up to date with the target branch.
This is roughly what happens currently when GitHub rebases a PR. |
We recently wrote a script that polls the PRs, automatically updates the oldest set to be rebased and performs the rebase once CI passes.
We would love to get rid of it, so we are eagerly waiting for a feature where we can set multiple branches to auto-rebase in order and automatically keep them up to date.
This is what I would like GitHub to do once I first set PR #1 to auto-rebase, followed by #2. |
Comments
Post a Comment