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'm shocked how many companies still don't focus on DevX and wonder why not only is productivity in the gutter, but morale as well. There's so many companies that help solve DevX problems like this, that's it's practically easy to throw money at it.
I believe in what Guillermo Rauch said: "Write tests. Not too many. Mostly integration." The problem that's not mentioned is that the higher-level tests you write the higher likelihood they'll be flaky. Testing is all about confidence that your code works and flakiness undermines that. Having tools to counteract this will allow me to ship faster and with better confidence. Very nice.
> 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.
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.
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.
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.
Without a doubt the easiest way to start would be with next.js. Segment.io has even built a scaffolding tool to create a next.js project https://open.segment.com/create-next-app
I keep track of all my projects using task management apps like Asana, use Git to backtrack what I have been doing on each project, and switch projects really often. This way I can make sure I am organized and can pick up where I left off and if I am at a roadblock with one project I can blow off steam by doing something really great on another.
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.
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.