[dukedylan]

I think your post is very practical in what is the norms for everyday development. I have a bit more of an idealistic pattern I wish I saw more people follow.

As for squashing, I believe that everything should be rebased instead to maintain a proper, linear git history. This maintains the ability to bisect and allows a descriptive git history. Temporary branches pass on their history to the main branch.

Even for temporary branches, labeling commits properly makes reviews easier, especially if commits are atomic. Ideally, all PRs are small and easy, but many times more changes than what's easy to glance at are needed. Understanding what and why these changes were made helps to walk through step by step—they're meant to decay since they are quite literally history. Reviewers should review the commit messages themselves and ask for revisions on them when needed. This is hard to enforce and requires thorough buy-in from people to invest in it. There's some proof in the pudding, at least, if you look at the conventional commits usage in the community.

(very, very idealistically—not very practical) To keep commits atomic, each commit should be tested incrementally, at least with static checks and unit-y (read faster) tests. Each commit must past checks prior to PRs getting merged.

[dapirian]

> As for squashing, I believe that everything should be rebased instead to maintain a proper, linear git history

Rebasing on your PR branches is up to you, it's subjective, but setting GitHub to rebase your PR commits onto your main branch as it's merge strategy is not proper at all. It might 'work' for a tiny hobby project, but it does NOT work for any kind of team activity / professional environment - it would be an immense amount of bloat onto your main branch, and git will eventually start to get slow as mud on every operation because of it. Fun fact, git performance does not scale linearly, and big monorepos hit this problem. Beyond performance, when looking through git history on the main branch: - Every commit on the main branch should map 1:1 with a reviewed PR that passed CI tests/checks - The 'mapping' can just be done by having the PR number in the commit message title. GitHub does that for you with the settings in this blog post - It's not uncommon that someone has 30+ commits on their PR branch, many of which are in a totally broken state, have blatant typos, etc. People just don't (and it's not even desire-able for them to) structure their local commits while working on a PR to be some kind of iterative working state that is useful for others to look at. It's beyond clutter to have these 30 broken commits with crummy commit messages like "update" rebased onto the main branch for all to see for all time.

[dukedylan]

Not necessarily real world, considering performance especially. Let's say that a project is smaller, git improves performance, or computers get more efficient:

Regarding commits relation to PRs: GitHub still maintains this with rebase and merge. It's linked in the UI when viewing any individual commit on a branch.

Broken commits are mitigated by testing each commit incrementally.

Commit messages must be reviewed and edited to make sense. Having 30 commits would be something flagged in review. It's okay and encouraged to make a bunch of commits during review and then require those to be rebased into logical, atomic commits prior to merging.

[dapirian]

If each of your commits are tested and make sense independently, they should be different PRs - sounds to me like you're just smashing 5 stacked PRs into 1 with highly fussy curated commits, which aren't guaranteed by github settings to each be passing CI

[dukedylan]

PRs are just logical groupings of commits. It makes it efficient to group related commits together. You are correct that each of the commits could be separate PRs which is part of the advantage to this pattern—code contribution is always atomic and easily organized. How you organize these contributions is done whichever way makes it easiest to get merged in efficiently.

[thunky]

I think the parent's point is that if you only just choose to think of the PR as the "unit of change" on your software product, rather than commits, all of this extra discipline you're imposing on yourself just goes away.

And what do you lose by making this decision?

The main branch, being the only place where the changes really matter, can still capture all of the necessary details of the changes (based on the PR) in the commit message when it's merged. This is the point where the curation is most useful, and where it's easiest to apply and apply standards, run tests, and actually enforce that they're followed.

[dukedylan]

> all of this extra discipline you're imposing on yourself just goes away.

I think the extra discipline is just shifted to the PR in that case instead of the commits. What's lost is the ability to make code contributions of related changes together in a PR which can be more efficient than making many small PRs.