Why I Git It
Yeah, I know. Cheesy title. But, it’s true. I’ve been using Git for the past several months and am amazed at it’s powerful simplicity. The concepts are easy to grasp thanks to great documentation and real world examples.
I’d heard all the rage about the other SCM‘s. I’ve looked into Mercurial and Bazaar, but wasn’t as impressed with them as I was with Git. After following the timeline of emails as Linus wrote and shared his new creation and watching his visit to Google, I gained a whole new respect for distributed revision control (DRC).
It’d been hard to miss all the talk around DRC, but thought it’s only benefits were to interact with my repository when I didn’t have connectivity. I was almost always connected, so my Subversion repository was all I needed – so I thought. Having read a post about cloning repositories, I decided to investigate why so many people were now using Git. While researching Git, another article about “forking” caught my attention and slowly I started to see all of the wonderful benefits I’d been missing by not using a DRC – specifically Git.
- Branching – the way it’s suppose to work! This is “throw away” branching at it’s best!
- Cloning – This is extremely useful when stumbling across projects on services like Github. Instead of the traditionally checking out a copy of the trunk or a branch in CVS and Subversion, Git clones the entire repository into a local directory for you and “…creates remote-tracking branches for each branch in the cloned repository”. A great example is Reddit. When they released the code, I cloned the repository and every few days I can run “git fetch” to update the remote-tracking branches. I can run “git pull” to update the remote-tracking branches as well as “merge the remote master branch into the current master branch, if any”.
- git-svn – Simply put, this is brilliant!!! Having all of my repositories in Subversion this allowed me to have a “trial run” with Git. I was able to make a local “Git clone” of my Subversion repository, interact with it and “sync” the changes I truly wanted committed to the Subversion repository. I could create as many throw away branches as I liked and the Subversion repository never knew anything about them. Needless to say, the VERY DAY I started playing with Git, I made my last commit to my Subversion repository and haven’t looked back since.
- git-stash – Again, BRILLIANT!!! Stash “saves your local modifications away and reverts the working directory to match the HEAD commit”. Every developer I’ve talked to about this with has the same reaction – (AWESOME!!!!) – as we’ve all been in the situation where they were working on a new feature and they need to fix a bug. Most of us have a “fixes” version of trunk in a separate directory for just this purpose. But with git-stash, you can have this freedom with a single working copy!
- git-diff – Git tracks content, not files. Each commit is tracked by it’s sha1sum, shown beside each when issuing a “git log”.
I was also impressed with the wealth of information and comparisons of Git with other SCM’s others had put together.
Recent news about Gist show the flexibility of Git repositories. Thanks to services like Github Git is gaining more respect and notoriety, almost like the movement when Subversion first came on the scene.