Staying Sane with Git

You might have seen it – @kkuchta christmas tree gif making the rounds these past holidays:

tumblr_inline_o0mdgf6twL1t74qoj_540

For a short story, that sums up my early experience with git with surprisingly accuracy!

For anyone else who’s struggled with git over the years, here’s a bit of my process to help me stay sane with git:

1. Where I am in the tree?

I use the command line to make new commits, pull, merge, etc, and when I first started using git I had a lot of trouble understanding just where I was in the repo at any given time. After branching a few times, I’d get lost pretty easily and forget which branch I was currently on. A simple fix – I added the following line to my .bash_profile:

# Put Git branch name it shell prompt
parse_git_branch() {
  git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
PS1='\W$(parse_git_branch)\$ '
`

This simply printed out my current location in my console’s prompt:

loose-leaf(master)$ 

Now I felt comfortable git add branch-nameing and git checkouting as often as I needed without getting lost.

2. Where I can go in the tree?

Now that I knew my location in the tree, I still wasn’t sure where I was in relation to all the other branches. For that, I use a GUI app called GitX-dev: http://rowanj.github.io/gitx/. It’s a fantasic and incredibly simple app that shows the history, branches, and tags of your git repo.

tumblr_inline_o0mf1nh6NQ1t74qoj_500

It’s incredibly handy for easily seeing at a glance where I am in relation to all of the other branches, both local and remote.

3. Where is the remote?

Speaking of remote – there’s been more than once where I’ve worked on a fork of a primary repo, so I needed to keep track of both the upstream original repo and the fork repo.

For that, two simple commands help me know what’s what:

# lists all of the remote repositories and their names
get remote -v

and

# fetches all of the branches and tags from the remote repo
git fetch remote-name

These two commands let me know if my local branch was still simply an ancestor of the remote branch – if so, I could git pull without fear of an ugly surprise merge.

If my local branch had diverged from the remote, then I could look through the recent commits for that remote branch in GitX, and then decide if I wanted to a) git rebase my local changes onto the end of the remote branch with:

git rebase branch-name remote-name/branch-name

or b) have more context going into the merge with git pull.

4. Where is my bug?!

Here’s the real gem that I’ve only recently started using to great effect: git bisect.

Git bisect is a magical tool that will help you find the exact commit that caused the bug you’re trying to track down. Simply put, it does a binary search through your commit history until it finds the exact commit where the bug appeared.

Assuming your repo is currently showing your bug, you can start the process with a simple:

$ git bisect bad
You need to start by "git bisect start"
Do you want me to do it for you [Y/n]? Y

Confirm the prompt with a Y, and then checkout a commit that you know doesn’t show the bug:

$ git checkout old-branch-that-worked

And then mark that bugless commit as the 'good' commit.

$ git bisect good

And now the magic has started! You’ll see something like the following show up soon:

Bisecting: 4 revisions left to test after this (roughly 2 steps)    
[uglycommithash] an old commit message

Git has started its binary search through your tree, and all you have to do now is tell it whether the bug shows up in this commit with git bisect bad or if it’s bug free with git bisect good. Just keep going until you finally see:

ugly-commit-hash is the first bad commit
commit ugly-commit-hash
Author: Definitely Not You

And that’s it! Now you know precisely where the bug is and have a much better chance of tracking down its root cause. At this point I usually git branch bug-name just so I have a temporary flag in GitX for me to look for.

Note: At the end of your git bisect, even though it’s shown you the offending commit, you’ll technically still be in bisect mode.

# at this point after a bisect, your git status will be:
$ git status
HEAD detached at 4751a0a
You are currently bisecting, started from branch 'master'.
  (use "git bisect reset" to get back to the original branch)

To return to git business as usual, simply:

$ git bisect reset

And Tada! You’re back at your original branch as if nothing had happened. It’s an absolutely invaluable way to quickly narrow down a tricky to find bug.

A little goes a long way

This writeup barely scratches the surface of what’s possible in git – there’s huge swaths of functionality I haven’t even touched on – but if I had to choose only a handful of features, this would be it. This is 99% of what I use when I’m interacting with a repo, and I wish I’d seen it when I first made the switch to git many years ago.

Leave a Reply

Your email address will not be published. Required fields are marked *