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

                      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/
                        Permalink On twitter.com Twitter logo develwoutacause’s avatar ♻️ 3 Retweets ❤️ 12 Favorites Mood +1 🙂
                    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.
                      Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood 0
                  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. 😉)
                    Permalink On twitter.com Twitter logo develwoutacause’s avatar ❤️ 2 Favorites Mood +6 🙂
                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
                  Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +9 🙂
              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
                Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +5 🙂
            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.
              Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +3 🙂
          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
            Permalink On twitter.com Twitter logo develwoutacause’s avatar ❤️ 1 Favorite Mood +3 🙂
        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.
          Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood -2 🙁
      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
        Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +4 🙂
    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.
      Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +2 🙂
  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. 😁
    On twitter.com Twitter logo develwoutacause’s avatar Mood +8 🙂
    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!
      Permalink On twitter.com Twitter logo develwoutacause’s avatar ❤️ 3 Favorites Mood +1 🙂
      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.
        Permalink On twitter.com Twitter logo develwoutacause’s avatar ❤️ 1 Favorite Mood +4 🙂