GitHub's PRs could be better

At work, we use GitHub to collaborate on code. We create short-lived feature branches and merge them back to the main branch via pull requests (PRs). This is a fairly standard workflow.

Unfortunately I’m not too happy with it. I’ve had trouble finding a perfect way of working with git and GitHub’s PR view.

I’d like to have the following:

Useful git history. There are many opinions on what makes git history great. Myself, I look at the blame annotations regularly, so for me descriptive PR titles are the most important part. Implement <feature> or Fix <bug> are great; Code review fixes or Make it work not so much. When using command-line tools, you can use --first-parent to see the merge commits instead¹, and in VS Code and on GitHub you can quickly jump to the PR that touched the line.

Easy re-reviews. As a PR reviewer, it’s nice if you can easily see what has changed since the previous review round. If the PR reviewer has pushed new commits, then it’s easy: GitHub can show you changes from the commits that were added since the last review. However, if the author has amended the existing commits and force-pushed them, then GitHub won’t do this.

No busywork or custom tools. When I’m ready to merge, I’d like to just press a button in GitHub to do so.

So, what’s the issue?

When you make changes to your PR after the first round of review, you need to either add new commits or amend the existing ones. If the changes are small, then it’d be better to amend them into the existing commits to avoid messy history, but then you won’t get easy re-reviews.

As a compromise, we sometimes create fixup! commits and push those. Once the PR has been approved, we then rebase them with autosquash, force-push, and add the PR to the merge queue. You cannot just merge by pushing a button on GitHub. Maybe we should script this, but this goes against my desire to avoid custom tools.

You could also consider using GitHub’s Squash and merge option, which squashes all the commits into a single commit on top of the default branch. This could be a great option if you do single-commit PRs anyway, except for one thing: now git on your computer cannot tell that the branch was merged. git branch -d will complain, git rebase -i will include stray commits, and if you use Jujutsu, jj git fetch does not hide the merged branch.

I’m not going to try to tell GitHub what they should do, but the situation does not feel optimal!

A general point: when we debate about how to best use git, it’s not just about git itself. It’s also about all the tools that integrate with git: the code forge, the editor, the CI system, etc. It’s also about the people with whom you use git.