Getting with Git for Groovy/Grails Developers
The official Grails repository moved to git back in March of this year. For anyone not yet using git for source control, I thought it might be useful to provide a general introduction to the benefits of git and how to get started – on a Mac or a PC. This posting tries to answer the question “Why git?” My next three postings will cover the practicalities of getting a Mac or a PC set up to work with git and then some initial instructions to start working with git.
Git is a distributed version control system. There are a number of key benefits it provides when compared to a centralized vcs like subversion, perforce, visual source safe or cvs (I’ll be comparing it to svn as that’s probably the most popular of the alternatives).
- Offline access – If you ever work offline or from a location that has a slow internet connection, you’re going to love git. Instead of just having a copy of a given tag, branch or the trunk, with git, you have the entire repo with all of the revision history, so if you want to revert to another branch or look at the history of revisions and run diffs between them, you can do that anywhere, anytime. And because you’re working with local files it is *really* fast.
- Fast, easy branching – The power of version control systems comes from the efficient use of branches to keep different streams of work separate, so you can be working on multiple stories at the same time while still keeping a clean trunk in case you need to push a patch live to production quickly. Branching in subversion is easy, but merging can often be painful (and changing branches can be slow as it’s a remote operation). With git you can make very quick changes between branches, and the merge conflicts are handled much more efficiently. The basic process is similar to subversion, but the number of conflicts that require manual intervention is usually much lower. With git, branching is easy enough that you’ll find yourself creating a branch for each story.
- Quick operations – Nothing sucks away developer time worse than slow operations – whether it’s checking out code, reverting to a tag or running a merge. With git, all of the operations are local (except for clone, pull and push) and they’re all extremely quick.
- No more politics – If you’re running an open source project (or any project with ad-hoc contributors) there is usually a whole set of politics and planning around who should and should not be a core committer. With git, anyone can clone the repo, make some changes and send you a patch. You can then just check out the patch into a branch, run regression tests against it, diff against the master to see what they changed, and then decide whether or not to merge their changes into master. It really lowers the barriers to contributions.
- No more orphaned projects – As long as one person has a copy of a git repo for a project, if they continue to maintain it, that can become the definitive resource for that project. There is no problem with a project lead getting busy and the project dying because patches aren’t being committed. As long as *someone* is interested in the project, it’ll continue to live.
- No central repository required – Do you create a repository for every single thing you do? Your notes? Your presentations? Your client meeting summaries? Your little “hack projects”? If not, the reason is probably the overhead of having to go to your subversion server and create a repo. With git, you just cd into a directory and “git init”. That’s it – instant repository. Suddenly there is no reason not to have a repo for everything, and you can always push your repo to a remote server if and when you want to create a central version (you can also just zip up your file system for the project and the user will have a copy of the repo and all of its history).
- A single git directory – Anyone else fed up with having to add code to your build scripts to kill the .svn directories scattered throughout your project? With git there is a *single* .git directory containing all of the revision history.
You might think that having a copy of the entire repo would make initial checkouts unwieldy, but because of an extremely efficient system for representing deltas, git repos are usually much smaller than a corresponding svn repo would be (with the usual disclaimer that lots of large, changing binaries in your repo are as bad an idea with git as with anything else). Often a git repo will only be 20-30% larger than a checkout of the trunk in svn – and it typically downloads extremely quickly.
There are a lot of other benefits that you’ll find as you start to get more familiar with git. You’ll learn to love the “stash” command and to appreciate the difference between the staging area and the repository. You’ll think up all kinds of non-traditional workflows that are possible when you aren’t limited to a single authoritative server, and you’ll find the power of everything from bisect (for narrowing down what part of a commit broke the build) to rebasing (flattening a set of minor commits into a single commit to balance the benefits of small steps with making your history log more meaningful). However, even if you use git as an enhanced replacement for subversion, you’re going to enjoy the improved speed and flexibility that you get so you can focus on coding, not waiting for your vcs. In the next article, I’ll look at getting started with git on a Mac.