At my new job we use Git, which is not exactly the type of a version control tool that I am used to. Instead of saying "Man I hate Git" I am going to first figure out why. Perhaps I am better off learning to use it, rather than fighting it. After all, I've seen a similar reaction from Visual SourceSafe old timers on a team I worked on when I tried to convince them to use CVS (and of course I've seen plenty of people who after years of using CVS still don't understand how to do simple things in it). I vow not to become one of those people who reject things they don't understand.
After years of using CVS and similar systems I've grown accustomed to the following functionality:
- There is one central authoritative repository
- When you checkout from the repository you get the latest version of your code and you work with it
- When you are ready to submit your changes you commit to the repository. If someone else touched the same file and there is a conflict the system makes you resolve it first.
- There is branching functionality such that longer-term development efforts can be isolated from maintenance releases.
- There is a way to tag a source tree to mark a release.
Git significantly differs from the above philosophy in a few key aspects (* what follows below is my personal understanding, please correct me if I am wrong):
- There is no central authoritative repository. All participants have a copy of the entire repository. At any given moment the project can be literally cloned off of one of the developers' personal copies. Maintaining a common version of the project becomes a manner of convention and agreement rather than a function of the version control system. If all developers agree to clone from one place, that "origin" repository may act as the authoritative copy. I can live with this -- after all, a VCS is not project management tool nor is it a communications tool. (UPDATE: there is a concept of bare repository, which may not be used for development but acts as a central authoritative repository)
- When you clone a repository you get the entire repository, everything you need to manage all versions of the files.
- Commits happen in sets. Changes are staged and committed in one step. I like that.
- There is branching functionality, but from what I gather you shouldn't be doing development in the "master" branch. You create a local branch in your own repository for code changes, then you merge master into it, then you switch to master and merge your branch into the master. This is similar to branch/merge workflow I followed at my previous job, so not entirely unheard off.
- Git too supports tagging
I guess the most confusing thing about Git for me is the fact that everyone has a copy of the repository. I certainly see advantages to this -- work can be performed off line with local history tracking and all the tools you need to isolate and manage your changes. But it differs significantly from what I am used to, so I am going to pick up a book and read up on Git this weekend -- so I can have a productive week ahead without a VCS tool getting in the way.
