One of Git’s core strengths are its simple, light-weight branches. Spend any time working with Git and you’ll soon develop the habit of creating feature branches for any change. As your project grows, you may start to introduce release branches, hotfix branches, and long-running feature branches.
Navigating between branches becomes a common task. A simple
git checkout <branchname> is all it takes. Not so bad, but if you’re frequently switching between branches, all the typing can add up.
That’s where git-j comes in.
git j is not only faster to type than
git checkout, but it also offers some quick shortcuts for fast branch navigation, making it just as easy as directory navigation.
Here, I’ll show you.
Go up a branch with
git j ..
Much like directory navigation,
git j .. jumps to the nearest parent branch.
Let’s say you have this branch scheme:
o [topicB] [HEAD] | o [topicA] | o [master] |
Say you want to go down a level to
topicA, do some work, and then go down again to
git j ..:
$ git j .. # Do some work $ git j ..
Now you’re on
master. Check out the savings compared to
$ git checkout topicA # Do some work $ git checkout master
Hey look, you’ve saved 22 keystrokes!
Jump to your previous branch with
git j -
Ever find yourself switching back-and-forth between two branches? We have a handy shortcut for that.
Let’s go back to our branch scheme from before. You’re on
topicB, and you need to go down a branch to
topicA, do some work, and jump back to
$ git j .. # Do some work $ git j -
Much nicer than the alternative:
$ git checkout topicA # Do some work $ git checkout topicB
That’s another 23 keystrokes saved.
Use aliases for common branches
You probably have a few branches you’re frequently on, and I bet one of them is
master. Let’s say that another is
release-1.0.x. Oh, let’s also throw in something like
2.0/big-refactor on top of that.
How often are you typing those branch names? Every typo any of them? I sure have.
We can shorten all those names with
git j alias. Let’s give them nice, short, easy-to-remember names:
$ git j alias m=master $ git j alias 1.0=release-1.0.x $ git j alias rf=2.0/big-refactor`
Now instead of typing those branch names, all you have to do is pass the aliases to
git j, like so:
$ git j m $ git j 1.0 $ git j rf
Much nicer than:
$ git checkout master $ git cehckout release-1.0.x $ git checkout 2.0/big-refactor
Wouldn’t you say?
I use that
m alias all the time, since practically all Git repositories have a
master branch. Instead of setting up an alias for all of them, I can make a global alias:
$ git j alias -g m=master
git j m will work wherever I go!
To unset an alias, just pass an empty branch name:
$ git j alias rf=
By the way, if you ever need to check which aliases you’ve set up, just simply type
git j aliases. For global aliases,
git j aliases -g.
Working with branch history
git j keeps track of which branches you’ve checked out most recently, and makes it easy to jump between them.
git j history to see what your branch history looks like.
Want to quickly jump to a branch in your history?
git j <number> is all you need. For instance,
git j 2 will jump 2 branches back in your history.
Putting it all together
Okay, here’s a big, real-world-ish example. Our Review Board repository has
release-2.0.x branches, and I’ve introduced a
my-feature branch. In this example, I’m going to:
- Work on
my-featureon top of it.
- Merge it into
- Merge the latest
- Go back to working on
First, here’s how you’d traditionally do this with Git:
# 1. Work on release-2.0.x. $ git checkout release-2.0.x # 2. Rebase my-feature on top of it. $ git checkout my-feature $ git rebase release-2.0.x # 3. Merge it into release-2.0.x. $ git checkout release-2.0.x $ git merge my-feature # 4. Merge the latest release-2.0.x changes into master. $ git checkout master $ git merge release-2.0.x # 5. Go back to working on release-2.0.x. $ git checkout release-2.0.x
Now let’s try it with
git j, and with a couple of aliases (
# 1. Work on release-2.0.x. $ git j 2.0 # 2. Rebase my-feature on top of it. $ git j my-feature $ git rebase release-2.0.x # 3. Merge it into release-2.0.x. $ git j .. $ git merge my-feature # 4. Merge the latest release-2.0.x changes into master. $ git j m $ git merge release-2.0.x # 5. Go back to working on release-2.0.x. $ git j -
How’s that for less typing? As you start to work with git-j, it’ll all start feeling more natural, just like walking a filesystem.
Get started with git-j today!
Simply clone our dev-goodies repository and stick
dev-goodies/bin/git-j somewhere in your path. Or, stick all of
dev-goodies/bin/ in your path to get easy access to all our scripts.
We’ll talk more next week about another extremely useful git script we provide called
git-rebase-chain. Stay tuned!