Git and GitHub: Wow.

I’m just getting my feet wet with Git, but it’s starting to amaze me more and more. At first, I thought, “Yeah, Git sounds pretty cool, but I can’t see learning a new VCS. I know SVN and it’s fine.” Wrong. Wrong. Wrong. Learn it and LOVE it.

Git is Distributed

Git is a distributed VCS as opposed to a centralized one. And what exactly does that mean? It means it’s faster, safer, and far better for collaboration.

It’s faster because all changes are committed locally, then pushed to the server at once. So there’s no need to have access to a SVN server at all times. You can imagine the performance gains you get from this. And subconsciously, having those somewhat expensive operations become nearly instantaneous makes you think/work a different way. A better way.

It’s safer because for each user who works with the code, there are multiple versions of the repository (each user essentially has his/her own copy (or branch) of the code). With a centralized VCS (i.e. Subversion), if the server hosting the single repository were to die, you had better hope there’s a backup somewhere. Otherwise, all is lost.

For a lot of (maybe most?) people using Git, collaboration is where its distributed nature shines. You can commit to your hearts content without disturbing anyone else. There aren’t any permissions issues because it’s all local to your machine. You can fork any project, change it however you see fit, then others can pull from your forked repo and merge with their own. And then that person can modify your already modified code, improve it, then tell their friends and they can fork the doubly modified repo, and, well, you see how this “network effect” can make projects blossom. This is entirely different from requiring commit rights to the one-and-only, centralized, repository. It’s a hard model to grasp at first, but it’s incredibly cool once you do.

Branching and Merging

Aside from being distributed, another thing that attracts me to Git is how branches work. Git encourages you to work from a branch, which is great because in concept a branch is ideal for experimenting with a feature. They remove the worry of “screwing up” existing code. And in Git, each “checkout” is actually a branch of the main repo, anyway. So naturally, merging branches works much better than that of many other systems. I think the creator of Git himself said he merges (on a 22,000 file project—the Linux Kernel) on average 4.5 times per day. That’s a lot.

Another cool thing, if you’ve branched (or forked) a repo that you don’t own, you can tell the owner about it (send a pull request) and he/she can merge it with the master branch if it’s worthy. And even if it’s not worthy, someone else might have the same need as you, and fork your forked repo instead of the master.

Learn it. Love it.

At first, I thought having to explicitly add files to the “staging area” was tedious and annoying. Now I think it’s brilliant. It provides more control. I add the files content of my choosing to the index for the next commit, so the commit messages are always meaningful, and it doesn’t hold back my work flow at all. Which brings me to another wonderful thing about Git: it tracks content not files. With Subversion, you know those .svn folders littered all throughout every folder in your entire project? Git just has one .git folder in the project root. And better yet, you remember having to tell Subversion you were deleting/moving each and every file (svn mv and svn rm)? No more. Git doesn’t care what you do. It’s smart enough to figure it out when the time comes.

Not sold yet? A great article called, The Thing About Git shows some advanced usage of Git, and in particular, the infamous Tangled Working Copy Problem that every developer using source control has dealt with. Go read it if you haven’t already.

So, I agree with everyone else who already realizes Git is awesome, because, well, Git is awesome.

GitHub

And then there’s GitHub, a place to host your Git repositories. It was built by the guys at err free, so you know it’s slick. GitHub really wraps a nice interface around the inherent benefits of Git itself. It’s said to be a “social network for programmers”.

They just launched publicly the other day. (I got in early as one of the beta users) With the launch, they’ve released two new features: commit comments and the network graph visualizer. Both incredibly useful and impressive, as expected.

The commit comments are similar to those of the Django Book. But since we’re dealing with commits, the comments can be per line of source code or per commit. Very cool.

And the network graph visualizer is cool because it exposes how Git actually works. If you read the post about the network visualizer, you’ll get to a part that says “think of this as a to-do list,” which at first, I didn’t get. Now I do. As I said earlier, with Git, you can fork a repository and make your own changes separate of the master branch. That’s just awesome in itself, and what’s even cooler is you can choose to pull changes from a forked repo back into yours. What the network graph does is show you what things others have been up to in relation to your code. But it only shows code that you have not yet pulled into your repo. Once (if) you do, it goes away, hence the comparison to a to-do list. And try clicking a user to the left, they become the root and the graph changes. Nice.

Conclusion

Overall I’ve got a long way to go with Git, but it’s exciting to keep learning it. Even as a beginner, I’m finding that I’m able to do more with Git than if I were using a centralized VCS.