What’s a technical skill that will increase your effectiveness, but isn’t programming? How about: being efficient your source control system’s command-line interface? Even though I’ve used Git for a while, there are some things I’ve picked only recently that have made me more efficient.
Did you ever have a time when you were using a hammer, slowly driving in one nail at a time? Then along comes someone with a nail gun and BAM BAM BAM, they’re done! …That’s what comes with using a more powerful tool. We use source control systems every day, yet many of us slowly click on things in a graphical UI, or slowly type out commands in their entirety.
The more you equip yourself with good tools and learn to use them well, the better you’ll be able to stay “in the flow” of development. For example, time spent learning keyboard shortcuts for Xcode quickly pays off. In the same way, the better you can use Git (or whatever you use for source control), the more it gets out of your way, letting you concentrate on the actual coding.
So I want to show you 6 simple things you can use to improve your Git workflow — a set of Git power tools. These tools generally involve one-time setup (except for one that is a fun, game-like tutorial). Put these tools to use, and you’ll find you can get more done, more quickly.
Why type more in the command-line than you have to? By installing the Git completion script, you’ll be able auto-complete Git commands. Not just commands, but also the options. And not just commands and options, but also the names of your branches and tags!
The script is available for various shells: Bash, tcsh, and zsh. Get the latest version here. If you already installed the script some time ago, check to see if you have the latest version.
You can copy the script to your home directory, but I don’t want it sitting there cluttering things up. So I rename the file, adding a dot prefix to hide it. Then I add it to my shell startup. Since I use Bash, I edit
.bash_profile and add
Install it yourself, then open a new Terminal window. Now try using the Tab key to auto-complete a command, or hit Tab twice to show a list of options. For example, from a Git repository, type “git che” Tab Tab, and you’ll see a list of the Git commands starting with “che”. Add a “c” to make it “git chec”, then Tab. It will auto-complete it to “git checkout”. Now hit Tab Tab, and you’ll see your list of branches.
Less typing means you can move faster.
Branching is one of Git’s key strengths. But it also makes it easy to lose track of which branch you’re in at the moment. You can type “git branch” to check, but wouldn’t it be great if you could just see where you are? Well, you can!
Install the Git prompt script somewhere in your home directory. Again, I like to rename mine with a dot prefix so that it doesn’t clutter things up. Then include it in your
.bash_profile start-up script like this:
This defines a function to show the name of your current branch. I like to use that function to define my command-line prompt, like this:
export PS1='$(__git_ps1 "[%s] ")\$ '
Whenever I’m in a Git repo, the prompt now shows the current branch:
And if I’m not in a get repo, it shows a simple no-frills prompt:
Most templates for command-line prompts have a lot more information. You may prefer that. But I like mine short and simple, to show me just what I need without taking up too much space.
There are popular templates for the Git prompt that show colorized information. I recommend against using these. Terminal text colors are helpful for output text, but not when mixed with input text. The control characters for switching colors still count as characters, so the display gets quite confused if your command goes across two lines — which happens often if the prompt is long. It also happens when you try to edit a command. So avoid colors in your prompt.
In Git, commits aren’t necessarily linear. Instead, they form a directed acyclic graph, or DAG. And Git provides powerful commands to let you rearrange that graph in any number of ways — including massaging it back into a linear sequence. But how do you learn all these complicated commands?
The best way is through an online game. Learn Git Branching is a remarkable visual tutorial. It’ll teach you a command with animated illustrations, then ask you to transform a graph from one shape to another. It’s really well made, and even quite fun.
Now you’re a Git command-line pro. But there’s one problem: the command line is great for a lot of things — but not for showing you the topology of your commit graph. To see a graph, it’s still good to have a graphical interface.
You can use any Git GUI you prefer. But I like GitX. It’s simple and free, and focuses on the graph. I find it handy for visualizing commits and branches.
One last, ultra-simple trick: When you create a new Git repository that you’ll be using often, make a command that will take you there in just a few keystrokes. I do this with Bash aliases. For example, here’s the example that motivated me to write this entire post:
alias mb="cd ~/Development/MarvelBrowser"
Now I can type “mb”, and I’m in the Marvel Browser project I’m creating for the TDD Case Study. I have aliases set up for the other repositories I work in the most, such as OCHamcrest (“och”) and OCMockito (“ocm”).
For being so simple, this tool is surprisingly effective at helping me stay “in the flow.”
Bonus: Here’s another Git power tool I came across while starting the Marvel Browser project. When you create a new Xcode project, you don’t want to check in everything to source control. User-specific files within the project should be excluded. OS X keeps Finder information in hidden files named .DS_Store. And I plan to use AppCode, which caches project information in a .idea directory.
Now you can certainly discover which files to exclude from Git, and build up your .gitignore item by item. But why spend the time, when someone else has already figured out what to exclude? Go to gitignore.io. There, I specified Xcode, OSX, and AppCode, then hit the Generate button. Out popped a fully-formed .gitignore file! This made it super-easy to create my first commit. I’m confident that my new repository doesn’t accidentally contain files that shouldn’t be there, and I didn’t have to spend any time on it.
These tools are lightweight, mostly involving one-time setup. But they also complement each other! From the Terminal, I type “mb” to jump over to the Marvel Browser project. The prompt switches to show the name of the current branch, keeping me grounded as I quickly switch branches using auto-completion.
If you’ve shied away from using Git from the command line, I hope this inspires you to give it a try. If you’ve been using the command line but have been typing too much, these tools will let you fly. Most developers can type faster than they can manipulate a GUI. And by moving faster with less effort, you will be less distracted by source control management. Your brain will be able to stay more focused on actually writing code.
What are some other Git tools that improve your workflow? And what about you folks using Mercurial? Share your recommendations in the comments below.
When I was a kid, programming was fun. But working in Silicon Valley, I saw poor code lead to fear, with real human costs. Searching for ways to make life better, I learned about Design Patterns, Refactoring, and Test Driven Development (TDD). Programming became fun again! I've now been doing TDD in Apple environments for 17 years. I'm committed to software crafting as a discipline, with the hope of raising us all to greater effectiveness and joy.
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.