This entry aims to be the first in a series of posts discussing version control software (VCS), related tools and effective work-flow. I apologize if you were looking for a write-up on the hit 2004 film Git-R-Done starring Larry the Cable Guy, but hopefully you’ll keep reading anyway! The focus will be on Git because, well, that’s what we use here at Neya Systems. I will touch on considerations that go into selecting a VCS and then focus on the gitk repository browser.
For any software start-up, there are numerous technical choices that need to be made. One such decision is which VCS to choose? Many things need to be considered:
- Should you choose a centralized or a distributed VCS?
- Open-source or propriety VCS?
- Custom match your customer’s VCS per project or stick with a uniform selection throughout your organization?
- Does your development platform support your VCS choice?
I’m sure the list doesn’t just end there and depending on your industry the considerations may be completely different. Quite often in mobile robotics, you will find yourself field-testing in the middle of nowhere without a solid network connection. Therefore, one major factor for us is to have access to our repository no matter where we are. For central VCS options, having a link to the central server is required to interact with the repository. When field testing, having the entire repository on hand is clutch and being able to commit bug fixes on your local machine is a huge win. Therefore, having a distributed version control system allows the developer to have the most amount of flexibility and control to solve problems as they arise. If you’ve even spent one day working around a robot in development, you know that problems most definitely will arise!
All criteria considered, for us the right answer was to use Git. It was initially developed by Linus Torvalds (the creator of Linux, you may have heard of him) to manage the development of the Linux kernel. It was built out of a strong hatred for CVS. I bet you’re sold already right? What if I told you it was Open Source (aka Free), extremely powerful, and widely used (aka lots of support)? Now that I’ve got your attention…
Git is really easy to get started with. Installing it is a breeze and setting up repositories is just as easy. There are numerous write-ups and tuitorials on how to use Git and how it works. An excellent one I always keep bookmarked is by Charles Duan titled “Understanding Git Conceptually.”
gitk: Repository Browser
What I really want to cover are some tools and commands that can help you get the most bang for buck when using Git. For this post we’ll focus on gitk, a repository browsing tool.
In Ubuntu, gitk has been split out of the git-core package and must be installed separately using the following command:
sudo apt-get install gitk
Other distributions of Linux may include gitk with Git, so there is a chance you already have it.
Now that you’ve installed gitk, go ahead and fire it up by typing gitk on the command line from anywhere within your repository. You should see a graphical interface that pops up and looks something like this:
What you are looking at is the current local commit history in the branch you have checked out. The upper left shows all of the commits and their relation to each other. The upper middle shows the author of the commits, while the upper right shows the date/time of the commits. Immediately below the list of commits is the SHA1 ID of the selected commit.
A yellow circle next to a commit indicates that it is the current HEAD. Solid green flags show where various branches point to in your repository. The bold green flag reflects your current working branch. The peach/green flags show which commit the remote branches (the ones on your server) point to. Keep in mind, where these branches point to currently on the server may differ from your local repository. If you see any bright yellow flags, they represent Git tags.
Using a mouse, one can click on any commit in the upper left and obtain more information in the bottom panes. The bottom right shows the list of files that were modified/created/removed in the selected commit, while the bottom left shows the diff of each corresponding file.
Integrating gitk into your Work-flow
Focusing back on the upper left, note that each commit has a brief description of what changes were made. A policy of having developers always annotate their commits with a well thought-out summary really comes in handy when viewing a sequence of commits. If your team is using a bug-tracking tool, listing the bug ID in the commit description can go a long way towards assessing the state of the software. The story told by the commit history is as valuable a communication tool as meetings and email. Using gitk following a git pull, acts like a diary of other team members’ progress. This can be useful to help predict how the software will perform as well as in understanding how other peoples’ changes effect your tasks going further.
File History using gitk
gitk serves another purpose at the file level. By typing gitk followed by a file name, one can see the commit history of just that file. This is extremely helpful when that age old question: “Hey, who changed this?” comes up. Using gitk filename, one can easily see the progression of changes that led to the current state of the file. Using gitk in this fashion can help to pinpoint a particular commit of interest. By noting the SHA1 ID of that commit and typing gitk followed by the SHA1 ID, one can see the complete set of files that were changed in that commit.
A compliment to the gitk filename command is git blame filename. This command reveals who the author is for each line of the file. Hopefully when using this command, you are in the spirit of inquiry and not blame! It’s a pretty bad feeling when someone tells you: “I typed git blame on your file and…..” Use some caution with your powerful new skills. Maybe the command git inspect would have been a better name for this functionality, but I digress.
Other Repository Browsers
gitk is just one of many repository browsing tools. SmartGit and QGit are just a couple of many options available to you. I recommend starting off with gitk since it is simple and easy to use and then experimenting with other browsers as your demands grow.
Hopefully after reading this entry you feel a little more comfortable working with a Git repository. In the future I hope to give some insight into incorporating branches into your workflow, in addition to using another handy tool called git-gui for managing your commits.