Git and I
Within the last year, I’ve started to use Git (a distributed version control system) to manage changes to my personal and academic projects. If you’ve used SVN or CVS before, the basic concept of storing multiple versions and committing changes is similar, but it’s otherwise a bit different: with Git, branching and merging is cheap (time-wise) and very easy, so you’re encouraged to branch and merge often. This fosters a healthy “keep the master (trunk) branch stable” habit while you continue development of features, each in their own branch. Additionally, Git has a concept of “staging” your changes – it doesn’t commit all of your modifications by default, so you can make sure that each commit is “atomic” – that it accomplishes only one thing. Even when doing weekly class assignments now, I use Git as a way to track my progress, incentivize rapid progress (committing changes gives a rush of energy), and store working versions without making many messy copies of my source directory. Read on for what I’ve learned and how to get started!
With Git, because it is distributed, you actually have the full development history available everywhere that you have checked out (“cloned” in git-terms) the code. You don’t need a central repository unlike SVN, though you can do so if you wish, and even simply use a directory over ssh (such as within your VRAC home directory, for my HCI colleagues) as a server to “push” your changes to, for backup and collaboration. This low overhead is what made it possible to start doing assignments in version control – if I had to set up my own SVN server and perform that module setup every week, I would still be using numbered copies of my source directory.
If you’re working on open-source software (or have a budget for a closed-source subscription), I highly recommend the GitHub web service: it provides a central Git server for your projects, an intuitive web interface for history review and source downloads, and useful collaboration tools. You can take a peek at my user page and undergrad senior project, which I have hosted on GitHub, to get an idea of what it can do. (I have no link to GitHub other than as a happy user of their free service.) There’s also Gitorious, which is a similar service, and whose server software is open source and available to install on your own server.
If you’re using Git for coding assignments, as I am, and are using Xcode and/or simple Makefiles on Linux (like for ME 557), you might be interested in using my “.gitignore” file. This file, normally hidden on Linux and Mac (edit it from the command line – see it with ls -a), contains patterns for filenames that git will ignore and not encourage you to track in version control. Interestingly, .gitignore itself should be added to your git repository for each project (not ignored), so that those settings will be available everywhere you clone the source tree. I’ve built up a good default .gitignore file that will ignore the OS X and Xcode generated files, as well as the files generated on Linux (.0) and the equivalents for Python on all platforms. It’s at least a good starting point – download it here: sample .gitignore file for Xcode and Linux – remember to rename it. I’ve also pasted it here:
# ignore xcode auto-generated files
# ignore osx noise
# ignore backups created by text editors
# ignore object/generated files
You probably also want to set your name and email address, though this is less essential if you are using Git only for personal projects on your own machine. The commands are:
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
Graphical Git on Linux
I really like the Giggle tool on Linux for Git management. It shows a nicely-printed version history with commit messages and a branch/merge graph, allows you to stage and commit from the graphical environment, and is generally an intuitive-feeling GNOME application. (Git itself is probably included with your Linux environment – “
sudo aptitude install git-core” will install it on Ubuntu. It’s installed by default on the Linux machines in the VRAC lab, but sadly the latest Giggle won’t compile there because the environment is too outdated.)
Git (and Graphical Interface) on Mac
I’ve been using the GitX application, and it seems like aside from tagging, I can do all of my typical workflow actions from within the application. You do need to install Git itself first, but there is an installer available. For command-line support, you might need to add this line to the bottom of your /Users/YourUsername/.bash_profile file:
It’s a hidden file by default – you can use the Smultron text editor and its “open hidden” menu item to edit it. Once you have all this done, you can work with any git repository using the graphical or command line interface interchangeably.
Other Articles and Starting Points
If you had your interest piqued by this article, here are some links I ran across recently related to Git usage that I wanted to share. Of course, the friendly Google is always useful as well if you have a specific question or interest.
- Remote Git Repos on Ubuntu: The Right Way – This might be called “the right way” but “right” of course depends on the context: for a lot of use, simply cloning over SSH will do the trick, and if you want more features you’ll probably jump right to a web frontend like GitHub or Gitorious.
- Pragmatic Version Control using Git – This is a book available for purchase, with several useful-looking chapters available free.
- Gitignore File for Xcode Projects, on StackOverflow – the people posting on this forum-style question have a number of other ideas on how to best set up your gitignore.
- Tagging, Building, and Releasing – This article shows a workflow for using Git for more formalized releases (open-source or commercial software style), and includes scripts to automate Xcode and Git for the process. Worth reading just for the “collateral knowledge” absorbed in the process.