Enable squash commits. Each PR should be squashed to a single commit. This makes the master branch linear and simple. This ensures each individual commit on master has been reviewed and is in a working state.

In non-minimal changesets, I would miss information/documentation about individual logical changes that make up the changeset. Commit separation that is useful for review will also be useful for history.

I prefer a deliberate, rebase- and rewrite-heavy workflow with a semi-linear history. The linear history remains readable, while allowing sum-of-parts changesets/merges.

It's an investment, but I think it guides into good structuring and thoughts, and whenever you look at history, you have more than a squashed potential mess.

Squash-on-merge is simpler to implement and justify, of course. Certainly much better than "never rebase, never rewrite, always merge", which I am baffled some teams have no problem doing. The history tree quickly becomes unreadable.

That sounds like pretty much exactly what we did at my last job, and it worked pretty well IMO. The individual commits in a PR didn't ever matter. I don't even think we used them for code review, except if it came up for review a second time after rework. In that case, we were able to just look at the new commit to see if the right changes were made.

And we definitely avoided basing off each other's branches. We had to do it a few times. The only times it went well was when the intent was to merge the child branch into the feature branch. If they were actually separate tickets (and the second relied on the first) it was generally chaotic. But sometimes, it was just necessary.

If ‘—first-parent’ was the default way that git log worked, I don’t think we’d even be having this argument over how to merge branches.

In my opinion, the best strategy is to always use a merge commit, and then when viewing master, always use —first-parent which will ONLY show commits on master. This gives you:

• a very clean, linear history
• the ability to let people work in their branches in their own way (it is ok to merge master into your branch multiple times without rebasing)
• you can dig into the history of any branch if needed
• it makes it easy to backport changes as you can cherry-pick out the merge commit which contains everything.

The problem is just the default log view of git and tools.

In a project I'm in there are 20 commits just labeled .. The only reason I haven't slapped them silly is they left before I started.

That kind of commit quality should only really be permissible on private projects, and as a reviewer, it's arguably acceptable to reject PRs with this kind of history.

You should be writing your commits to the benefit of the code reviewer - structure them in a logical fashion to tell the story about the changes you want to get merged.

For non-trivial branches I usually soft reset to the point where all code is unstaged and uncommitted and then curate the commits to align with what the reviewer should be reading. It's not uncommon for me to have several branches containing a single "wip"-commit which I amend onto while building up the full code for the branch.

While exploring solutions, I use f or ffto mean "follow-up/to-squash" and a to mean logically separate. Sometimes other (additional) short abbreviations to know where to move, squash, and edit the changes to.

Other than maybe initial development until the first stable/usable version, these never persist, though. And even then, only if it's not a collaborative project. If it is shared or collaborative, "Iterate on x" is preferable as a non-descriptive title.

I guess my commit descriptions get better with project lifetime, not worse.