Using 'Git rebase' to Perfect Commits
adamjhawley.github.io
adamjhawley.github.io
To do this, I'll generate the diff of my work relative to the base branch and then stage parts of that work using the git apply command and make a commit out of it.
If it turns out that I need to update what I changed in a commit I already made, I'll just make a fixup commit (by creating a commit with the changes and titling it with
fixup! Exact title of commit
If I just need to update the commit message itself, I'll do the same thing except that I use the squash! prefix instead of fixup!. I then make the commit using the allow-empty option (making sure I have no changes states in the git index). During the autosquash rebase, this brings up the editor where I can delete the text except for the updates commit message I typed earlier.
What about making smaller commits and going back and editing it later? You could either 'git reset --soft' to "undo" some commit(s) and then craft them how you like, or anything else. Seems like your git skills should easily be good enough to handle that.
By the way, you know about 'git add -p', right? That's a fancier way to do what I think you're doing with diff and apply, though yours may work better for you.
Backups can be made independent of source control.
> What about making smaller commits and going back and editing it later?
In experience, it's actually more time consuming to restructure an existing set of commits (especially if they're making changes to the same files and same lines of code) compared to just making a new set of commits.
> By the way, you know about 'git add -p', right?
I am aware of it, but I'm not a fan of the menu based approach. When I stage code with git apply, I actually use vim's feature of visually highlighting the part of the diff I want to stage and filtering those lines through the git apply command. I can skip things like debug statements I've added to the code when staging. I can also unstage code by using the same command with the -R parameter.
I even commit within vim by reading the output of git status -v, writing my commit message and filtering that message through git commit with the -F parameter to have it read from standard input.
They can be, but it's ~hard to do it in a way that lines up with saving all your work, and you miss out on conveniences like the reflog (eg what was the state of _this_ branch half an hour ago?) Zfs snapshots can do it if they're manual or ~minutes apart and automatic, but that's a pretty blunt tool for this IMO.
> In experience, it's actually more time consuming to restructure an existing set of commits [...]
That's fair, but you _can_ just do that. If you have the commits in the first place, you have the choice. 'git reset --soft master' for example is "I don't want those commits on this branch anymore, but I want the final changes to rework into new commit(s)". I'd say about half the time I nuke the commits, half the time I rework them or they were just good enough already.
Sounds like you have a workflow that works for you though, just throwing out ideas in case they help.
> I am aware of it, but I'm not a fan of the menu based approach.
Agreed, it's sometimes tedious. I'll look into the way you do it, seems like for larger ~features your way might be less annoying.
To be fair there's a middle ground. You can just commit as WIP and force push to save progress. Then undo that commit and start making the individual commits. Everyone's happy.
"cws" to change "pick" to "s" ("cwf" for fix up), then "j." to repeat for the next line.
Also one of my favourite aliases is "rn" for interactively rebase the last n commits. Something like "!git rebase -i HEAD~$1" (from memory).
The standard vim {in,de}crement commands are bound to :Cycle in rebase buffers as well, so you can use <C-{a/x}> from anywhere in the line to twiddle the command for the current commit.
¹ :e $VIMRUNTIME/ftplugin/gitrebase.vim
C-Ve}c
Move to the end of the word.
Move down to the end of the paragraph.
Change the highlighted text in one.
Once you think like that it trips off the fingers from muscle memory.
The only use I could imagine is, if you have very short-lived branches (i.e. 1-2 days) with lots of random commits. Like e.g. "Oh I'm going for lunch, lets commit."
This is certainly not typical.
When working in a team, you may need to push something half-finished so that someone else can work on what they need to. Or testing something before refactoring.
For these scenarios, rebase is very handy for cleaning things up before merging.
If I clean up something I only do it for new commits before they are ever pushed to remote. My rule is basically to never rewrite history, that someone else might already have checked out on their machine.
I use SourceTree as my primary Git GUI, largely _because_ it has a UI specifically for interactive rebasing. Fork is another good GUI with interactive rebase support.
[0] https://blog.isquaredsoftware.com/2021/01/coding-career-git-...
You can easily work on, perfect, and re-order hundreds of patches in a single branch.
For one thing it doesn’t just edit history, it rebases the branch (shocking!).
Also, you run into extreme weirdness messing with the main (first, not default) branch and initial commit.
I’m an experienced user, so I understand the logic behind the weirdness, but I always caution new developers about it.
It’s “git rebase” not “git branch —edit.”
I know that some people say using CLI from the beginning is best for learning git but the visualisation from a GUI definitely helped me get to grips with the concepts.