Ask HN: What is your Git commit/push flow?

I do exactly as you say: commit early and commit often. However, something I find quite successful when publishing a Pull Request (aka CR/MR), especially large ones, is that I'll use git rebase to group chunk diffs together in a logical flow to create an easy-to-review set of commits.

If I have 5 commits that are all whitespace changes, I'll use git rebase to group them into one commit before I push.

If it's a large, complex PR, then I'll reorder my commits and pick-and-choose chunks from the many commits so that they make sense in a progression. For example, I might just add one new component in the first commit. Add a second component in the second commit. Third commit might be integrating those two components into the system.

If my PR consists of both "cleanup" like running black on python, then I'll make that its own commit instead of littering actual functional changes within cosmetic ones.

I try to make it as easy as possible for my reviewers to review my code and actually catch mistakes. I also tell the reviewers to look at the commits separately and not to look at the entire diff which can sometimes be hundreds of thousands of lines of code. Even a large PR with 500+ lines of changes can be easy to review if you structure the commits right. (It's really like many PRs within one PR.)

You may ask, why not have separate PRs then for each commit? Sometimes, that makes sense when it's so large that it's worth having an integration branch that lasts weeks or months. Sometimes, it's not possible to just merge that one commit due to problems it'll cause with compilation or linting or other issues. Also, with separate PRs, it can be more costly (in both CICD resources and the dev's time) to do automated testing on each commit separately.

With some practice, the git rebasing and reordering or restructuring commits is not as difficult as it sounds, especially with the aid of a good git GUI (I like Fork.app) that lets me choose exactly the chunk to commit from a particular diff.

Once I got really comfortable with this workflow, what I'll actually starting doing is... when I'm done with something and ready to put up a PR, I'll flatten (fixup) all my commits into one, and then I'll revert it and commit that. Then I revert the revert but instead of committing that revert-the-revert, I'll stage it. This gives me all of my changes in a staged state. Then I'll pick-and-choose chunks from that entire diff to craft a "narrative" like I was describing before. Once I have everything in the right order, I'll drop the first two commits to get of the initial and revert commits.

I commit/push to a remote branch often mostly as a backup/easy undo. My commits are squashed for each PR; if I have two commits that I want to stay separate, I send them as separate/chained PRs (I like the idea that each commit in master represents a reviewed point in history).

Create a feature branch for everything i work on. Then squash all commits on that branch for merge. If that doesn't look clean because there are too many features munged together, then split that feature branch into multiple ones (ideally would have already realized this ahead of time), then squash and merge each of those. So, then the main branch commit history is only "clean, completely functioning features" and then a link back to the PR that then has the full history of commits that got squashed, if you wanted more insight into the development process. The github UI simplifies a lot of this process and makes it a lot nicer to view.

GitHub/Gitlab allow you to rebase your commits when merging. We do that, but has the disadvantage of mucking up things for people who are using that commit. I personally think it’s worth it

I often commit as well to checkpoint, and push those onto a branch organized under my username as a backup (/ to make use of ref folders). When I’m done, I use interactive rebase to clean the branch up, writing meaningful commit messages for each unit of change (answering the question “why does this commit exist?” usually). I force push that cleaned up branch and then open a PR.

My view is that final commits are a form of communication, and deserve some intention. I’ve thanked myself when I’ve looked years back at work I’ve done and been able to figure out not only the change, but also my own state of mind.