9 karma · joined April 6, 2015
https://github.com/dfrankland/envoluntary
This helped me bridge the gap between installing packages declaratively via NixOS / home-manager and defining them for each project being worked in via flake.nix / direnv / nix-direnv; which was needed since most projects don't use Nix.
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.
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.
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.
Another helpful thing is to use code linters to prevent simple typos and other easy-to-miss errors. Atom editor, for example, has tons of linter plug-ins, as well as other helpful things, to ease creating code.