-
I was listening to this @CodingBlocks deep dive of #Git today. I use the rebase workflow a lot and wanted to share a couple tips and tricks I've come across. @iamwaltuo @THEjoezack @theallenu codingblocks.net/podcast/git-from-the-bottom-up-rebasing/
-
The topic of whether or not to use
git rebase -i HEAD~20
came up repeatedly. I have two alternatives: If you're in a feature branch, dogit rebase -i main
and it will limit to just that feature branch. If the repo is small enough, dogit rebase -i --root
for everything. -
Consider using
--exec
when you want to make sure something works for every commit. Very useful for testing feature branches. Before I make a PR, I'll run: git rebase main --exec "npm test" (Also works well withbazel test //...
since you get caching and 3P deps updated. 😉) -
Free tip of the week for you: I use #Emacs and love #Magit for interactive rebases. It provides syntax highlighting, easy rearranging, single key updates (press
s
to squash), etc. Very useful if you're a terminal Git person and like Emacs. emacsair.me/2017/09/01/magit-walk-through/#:~:text=specialized%20log%20buffer.-,Rebasing,-The%20rebasing%20popup -
One common workflow: When I need to respond to a comment on a PR about some commit in the middle, I'll usually do something like: $ git rebase -i main #
edit
the relevant commit. # Make the fix. $ git commit --amend $ git rebase --continue -
Another workflow: When I want to fix a bug and make sure it works at the *end* of the branch, but actually *commit* it earlier. I'll do: $ git checkout ${BRANCH} # Edit and test the change. $ git commit -m "WIP" $ git rebase -i main # Move WIP to the middle and use
fixup
. -
A few related aliases I have are: # Amend and keep the original commit message. git amend => git commit --amend --no-edit # Interactive rebase of a feature branch. git rb => git rebase -i main # Execute command for each commit in the feature. git rbx => git rebase main --exec
-
One unique workflow I'll use is "uncommitting and recommitting". When you edit a comment in an interactive rebase, most IDE's don't show existing changes in source control, which is annoying and makes it hard to remember what/how that commit worked.
-
I'll "uncommit" to put all the current commit's changes back into the working directory, make a fix, and then "recommit" when I'm ready. $ git rb #
edit
a commit. $ git uncommit # Put commit into the working directory # Make the change. $ git recommit # Restore commit message -
The aliases for both those commands are: git uncommit => git reset HEAD~1 git recommit => git commit --reedit-message=HEAD@{1} This is quite useful but can be fiddly (if you
amend
instead ofrecommit
you'll hate yourself). If someone has a better approach, I'm all ears. -
That's everything I can remember wanting to yell during the podcast. Hopefully some people can gain a useful trick or two when working with Git. 😁
-
Bonus tip - Add to your
.gitconfig
:[pull] rebase = true
And
git pull
will rebase instead of merge by default! If you prefergit pull --rebase
, you now no longer need to remember that flag! -
Bonus bonus tip - One more alias:
[alias] lg = "!git --no-pager log main~1..HEAD --oneline #"
Run
git lg
in a feature branch and it will list all the commits in that branch (commits frommain
). Useful for remembering what you were doing in that branch.