The PR and original branch show dead-ends that should not be required reading to understand things.

That way, I can treat the series of merge commits to trunk as the simple, linear overview of history, but when I'm bug-hunting I get small, clear commits to search through with git bisect.

It also means I get more useful blame output, as instead of huge hunks of a file being all from one giant bomb commit, I can see the process and evolution that the whole change went through as the original author pieced it together. That can be really helpful when dealing with obscure bugs or understanding systems with little documentation, by helping you get back more of the original author's thought process and seeing how their mental model evolved as they built the feature.

For example:

When I want to see tests or documentation or config related to a change, I'll find the commit and look for other lines changed at the same time.

When I make automated changes to the code, like reformats, auto-corrections by a linter, or IDE refactors, I create a separate commit to separate mechanical changes from those that require more human scrutiny.

In some ways it is unfortunate that services like GitHub and GitLab have become so dominant in the industry. If you're just working with plain git there is no assumption that squashing is some kind of binary decision the way the UIs of the online VCS services tend to present it. It's normal to do an interactive rebase and squash some commits to clean things up before sharing your code, yet keep logically separate changes in their own distinct commits, and you can have a much nicer commit history if you do than with either the no-squash or squash-everything extremes. Of course you can still do that with something like GitHub or GitLab as well but I think perhaps a lot of less experienced developers have never learned how or even why they might want to.

• All commits SHOULD pass all CI tests

• Merge commits MUST pass all CI tests

The reason I don't require every commit to pass all tests is to maximize reviewability and logical consistency of commits.

For example, if a file needs to move, and then be modified slightly to function in its new location, I prefer to break that into two commits:

1. A verbatim move operation. This commit will fail CI but can be effortlessly reviewed.

2. Small modifications. This commit will pass CI, and its reviewability is proportional to its size.

In contrast, if you smush those two commits together, it can be hard to see where the meaningful changes occur in one giant diff. (Some tools may be smarter about showing a minimal diff for a move-and-modify commit under limited circumstances, but that doesn't always work.)

All of these constraints can be enforced programmatically, and if you're going to adopt them at all I think automating them is the way to do it.

Personally, whether I enforce this branching strategy varies from team to team and project to project.

Many projects I've been on had much, much bigger issues to deal with, so something second-order like this never gets to the top of the stack.

That said, it's an approach I like, and I think it yields benefits if you have a team that's bought into it.

The "right" answer is probably to refactor the test suite to be more performant, but that's never going to get approved given the amount of work that would take, and it would take me longer than I plan on being at the company to get it fixed in my spare time.

I do have it passing all tests before I try to merge if that counts?