Ask HN: What is your Git commit/push flow?
Here's how I address this problem.<p>When I'm developing, but before I create a PR, I'll create a bunch of stream-of-consciousness commits.  This is stuff like "Fix typo" or "Minor formatting changes" mixed in with actual functional changes.<p>Right before I create the PR, or push up a shared branch, I do an interactive rebase (git rebase -i).<p>This allows me to organize my commits.  I can squash commits, amend commits, move commits around, rewrite the commit messages, etc.<p>Eventually I end up with the 2-4 clean commits that your coworkers have.  Often I design my commits around "cherry-pick" suitability.  The commit might not be able to stand on its own in a PR, but does it represent some reasonably contained portion of the work that could be cherry-picked onto another branch if needed?<p>Granted, all of the advice above requires you to adhere to a "prefer rebase over merge" workflow, and that has some potential pitfalls, e.g. you need to be aware of the Golden Rule of Rebasing:<p><a href="https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing" rel="nofollow">https://www.atlassian.com/git/tutorials/merging-vs-rebasing#...</a><p>But I vastly prefer this workflow to both "merge only," where you can never get rid of those stream-of-consciousness commits, and "squash everything," where every PR ends up with a single commit, even if it would be more useful to have multiple commits that could be potentially cherry-picked.