My first real introduction to Git and GitHub was at last year’s ZendCon. I’ve been using Subversion, a centralized revision control tool, for a few years now and it has changed the way I work. For example, I think in terms of changesets or “commits” that fix a defect, make an enhancement or complete a task in my codebase. It’s a workflow that has served me well.
I’d heard about distributed revision control tools before last year’s ZendCon. I thought it was a neat idea but didn’t really get what the advantage was over a centralized tool like Subversion. The folks from GitHub had a vendor booth so I thought I’d ask them why Git was better than Subversion. I forget exactly what they said (probably something about how branching and merging is so much easier in Git) but whatever it was it definitely made me consider trying Git.
The GitHub folks were wearing t-shirts that said, “fork you” and explained that on GitHub they encourage projects to fork. Typically in free/open source projects forking is considered a bad thing. It usually signifies some breakdown in the community when one project forks from another. However, with Git and GitHub it’s really easy to “clone” a project’s repository, hack away at some changes, and then “push” (or have “pulled”) your changes back to the repository you originally cloned. Git makes branching, cloning, pushing/pulling, and merging very easy and GitHub provides a place to host your repositories making this interaction with other people’s repositories very simple.
GitHub’s tagline is “social coding.” With distributed revision control each developer gets his or her own project repository. If your repository is public then anyone can come along and make a clone of it giving themselves their own copy of your project to work on. Assuming their clone is also public, you can track their changes and decide if you want to pull in work they’ve done. If you find yourself collaborating a lot with a particular person that you trust, you can give them the ability to push to your repository. With Git this actually scales to projects with lots of contributors. This may seem chaotic, pushing and pulling changes to and from decentralized repositories, but it’s actually a great way to encourage ad hoc collaboration.
If you want to learn more about Git you can read the Git Community Book, Pragmatic Version Control Using Git or the Pro Git Book. One last thing: if you’re currently a Subversion user then forget everything you know about how Subversion works. While a lot of the commands may be similar to Subversion and there’s a way to integrate with Subversion (git-svn), Git is fundamentally very different than Subversion. If you try and equate the two you’ll most likely end up confused!
