Falling in love with Git
Ever since watching Linus Torvalds’ talk about two years ago, I was excited about Git. However, it was only half a year ago that I first used it for one of my own projects during an internet outage. I’ve been working with Git extensively for a while now, and I’m still impressed.
Here’s what I love about Git:
- Distributed. I didn’t know about distributed version control before watching Torvalds’ talk, but it all made sense to me immediately – especially when thinking about open source projects. Clone a repository, work with it, create your own branches, collaborate on something with someone else and contribute back to the project by having them pull your changes or by creating a patch with the built-in command. Just brilliant.
- Powerful. I’ve never seen a source code management system as powerful as Git before. You can create and merge branches easily (git checkout/branch), you can store your current changes, work on something else and restore them later (git stash), you can employ a Subversion-like workflow by pushing to one or more remote repositories (git remote/push/pull), you can use Git to work with CVS (git cvsimport), Subversion (git svn) and lots of other SCMs, you can create and apply patches (git format-patch/apply), you can do regression testing (git bisect) and more. Despite all its features, I find it remarkably easy to use, probably because I grew up with Unix, and Git is Unix philosophy at its finest.
- Fast. It’s hard to believe how fast Git is. Cloning a whole repository, including the complete history of all branches is a matter of seconds for my typical project size. Plus since you’re working locally 99% of the time, you hardly ever have to wait on the network. When switching branches for the first time, I thought something went wrong because it took just one second.
- Github. Github is definitely one of the great things about Git. Besides hosting your projects conveniently, you can follow other projects and developers to see what’s happening in a Twitter-like timeline and you can fork other projects at the click of a button. For instance: I just cloned a project from Github and made some local changes. Since I had only read access to that repository, I simply forked it on Github, added it as a remote repository in my local repository and pushed my changes to it. I then removed the original repository from the list of remotes and I could continue to work as if nothing had happened. And all that in about one minute.
You can see how amazed I am. However, I have little hope of introducing Git where I work. The Eclipse plugin EGit is simply not there yet, nor is Windows support, and considering how difficult it was to replace CVS with Subversion, it seems surreal to think about using Git there. At least I’m Git-only for all of my private projects by now.
But if you can chose your own tools, I suggest you give Git a try even if your team is using a different source code management system. If you’re a Subversion user (I’m not a Subversion hater like Torvalds, I still like it in fact) I can point you to a very nice introductory series of screencasts demonstrating how you can collaborate with Subversion users.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)