develwoutacause’s avatardevelwoutacause’s Twitter Archive—№ 1,652

                1. 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/
              1. …in reply to @develwoutacause
                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, do git rebase -i main and it will limit to just that feature branch. If the repo is small enough, do git rebase -i --root for everything.
            1. …in reply to @develwoutacause
              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 with bazel test //... since you get caching and 3P deps updated. 😉)
          1. …in reply to @develwoutacause
            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
        1. …in reply to @develwoutacause
          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
      1. …in reply to @develwoutacause
        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.
    1. …in reply to @develwoutacause
      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
  1. …in reply to @develwoutacause
    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.
    1. …in reply to @develwoutacause
      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
      1. …in reply to @develwoutacause
        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 of recommit you'll hate yourself). If someone has a better approach, I'm all ears.
        1. …in reply to @develwoutacause
          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. 😁
          1. …in reply to @develwoutacause
            Bonus tip - Add to your .gitconfig: [pull] rebase = true And git pull will rebase instead of merge by default! If you prefer git pull --rebase, you now no longer need to remember that flag!
            1. …in reply to @develwoutacause
              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 from main). Useful for remembering what you were doing in that branch.