I’d encourage anyone using Git take a closer look into “git rebase -i” (interactive rebasing) combined with “git add -i” (interactive staging).
While working, I’m freely taking advantage of Git’s capabilities on a personal level, producing many sometimes messy WIP (work in progress) commits, trying things on short lived branches, reverting changes, and so forth, but afterwards I am able to copy edit the results to produce a sequence of finalized commits that form a coherent narrative that reads like how I would describe my work to a colleague or manager.
To me, interactive rebasing has been the difference between “my team uses Git” and “I first and foremost use Git for myself, and then also use it to share the results with my team”.
I nearly always "git rebase -i" before opening a PR, and even after. Squash, re-order, reword FTW. Recently I started using "edit" to split previously squashed PRs back out.
While working, I’m freely taking advantage of Git’s capabilities on a personal level, producing many sometimes messy WIP (work in progress) commits, trying things on short lived branches, reverting changes, and so forth, but afterwards I am able to copy edit the results to produce a sequence of finalized commits that form a coherent narrative that reads like how I would describe my work to a colleague or manager.
To me, interactive rebasing has been the difference between “my team uses Git” and “I first and foremost use Git for myself, and then also use it to share the results with my team”.