Join Our Newsletter

Apple

Spotify

Google

RSS

Episode 6 - Underused Git Commands that Simplify Your Life

15 mins
2020-03-30 engineering

Today, git is the standard for distributed version control. Services like GitHub and GitLab have made it very popular. But while many developers know the basics, a lot of us still think of it as magic and are unaware of the “power tools” that come with it.

We’ll discuss a number of commands or command options that will help you be more productive.

Reset

  • Use git reset to change the current state to the last commit or any commit you specify.
  • It’s common to use --hard commit_hash to move an entire branch to another commit.
  • There’s also --soft to point HEAD at a given commit and stage all the intervening changes. It’s like doing a squash without using rebase.
  • And there’s --mixed which does the same thing, but does not automatically stage the changes.
  • These are great ways to avoid deleting your repo and starting over.

Cherry-picking

  • Cherry-picking pulls the content from a commit in the form of a “patch” and then applies it to another branch.
  • You only get the content from that one commit, without any of the baggage of the branch history.
  • The process is simple:
    1. Use git log to identify the commits you’re interested in.
    2. Then check out the branch you want to apply the patches to.
    3. Then use git cherry-pick COMMIT_HASH.
  • If you have conflicts, you’ll get a prompt to handle it like a merge.

Amending

  • I often forget to add a file to the commit I just made, or to include some extra descriptive text in the message.
  • You can avoid adding a new commit by just amending the old one with git commit --amend
  • You can add --no-edit to keep the same commit log message.

The Stash

  • Sometimes you need to change branches while in the middle of working on something, but are unable to do so because you have unsaved changes.
  • Instead of committing the changes, or removing them, you can type git stash to store them temporarily.
  • When you’re ready to pick those files back up, you can go back to the branch you stashed and use git stash apply to retrieve your work.
  • It also keeps the stash saved in case you want to apply it again. Use git stash pop to discard the files.
  • Few people know that you can have multiple stashes. List them with git stash list.
  • You can also give them a name with git stash save "SOME NAME"
  • Applying a saved stash is possible by using git apply stash@{identifier}

The Log

  • Most people run git log to look at commit history, but few know about these extra features.
  • --stat shows a list of files changed in each commit.
  • You can constrain the number of commits to show with -n NUMBER.
  • Apply search criteria to the log with parameters like --after and --before to search within given dates, or --author for a specific developer, or --grep.
  • Even better, restrict the list of commits to a specific file that you care about using git log FILENAME.
  • Abbreviate the commit list to only include the hash and a one-liner message with --pretty=oneline.
  • Use --oneline for a shortened SHA.
  • --pretty has a few other variants like short, medium, full and fuller, go check them out.
  • Another really useful one is to use .. to show the commits between branches. git log origin/master..HEAD will show what you have locally that hasn’t been pushed to the origin.

Bisect

  • One of the most powerful - and almost magical - commands that’s great for debugging.
  • Use it to run a binary search between good and bad commits to find where in time something broke.
  • Here’s how it works:
    1. Switch to the branch and run git bisect start.
    2. Find the broken commit and use git bisect bad.
    3. Tell git about the last known good commit git bisect good COMMIT_SHA/BRANCH/TAG
    4. Git switches to a commit in the middle for you to evaluate.
    5. Run your tests type git bisect good if it’s working, or git bisect bad if it’s broken.
    6. Git picks another commit in the middle of the bad and good revisions.
    7. Keep repeating until you get down to the commit responsible for introducing the bug.
  • Make it even better with an automated test to help determine the broken commit. You can plug them into the bisect command with git bisect run TEST COMMAND and git will figure out the breakage point automatically.
Background music by Vendredi from Audio Library+
© Copyright 2020 - tryexceptpass, llc