Wed, 14 Jan 2009
I have finally got my feet wet with git.
I have been playing with it before, but now I did some real work using it.
There is a plenty of articles comparing
git to other SCM systems,
mostly pointing out advantages of distributed SCM. I will not repeat it here
(altough it is also an important point), I will write about what I find
most appealing on
- Unlike Mercurial,
branches are first-class citizens in
hg, you are often better cloning the repository than undergo the pain of using
- Readability of changesets
gitmakes it really easy to make the development work readable by others. I.e. it allows the flow of changes to be neatly split into logical pieces, which can be then read, reviewed, and individually applied by others. This includes not only git-format-patch(1) which takes the history and makes each commit a separate RFC822-like file which you can mail to somebody else (and git-am(1) on the other side), but also
git commit --amendwhich allows to edit the previously commited data. So as long as you do not publish the repository, you can rewrite the history as you like.
- ... AKA git-stash(1): you can postpone all your work just to commit a simple fix to something else, and then switch back to your long-term work.
- It is fast!
- ... altough I have to find out when to call
git gcand when/what to repack to be even more efficient.
- No special server-side software to publish your changes
- (not only
git-specific) The repository is a directory structure which can be published e.g. via HTTP by any HTTP server. So when I wanted to contribute to some project, I just cloned its repository, commited my fixes, cloned it again to my public WWW space, and then mailed the developer "please pull from this URL and let me know what do you think". Zero-cost public repository setup (remember how long it took SourceForge to provide a public SVN repository?). Zero "politics" amongst developers (no "I have a commit access" anymore).
After having used CVS for many years, Subversion for some years, and briefly BitKeeper, Arch/tla, and Mercurial, I think Git is by far the best one (that reminds me: do not bother to read any articles comparing Git < 1.6 with Mercurial - present Git is very user-friendly and well-documented). So the message is: do not even thing about using a centralized VCS for new projects, and amongst distributed VC systems, at least have a look at Git.
What is your own experience with version control systems?
1 replies for this story:
Milan Zamazal wrote:
Your conclusion is right. git is a clear winner among new version control systems. I've been using it for about two years, only in simple ways, but it nevertheless assured me this is the right system to use. git may not be perfect, but it works, it's well maintained and its future looks well. Other distributed version control systems I tried before didn't have all these properties (although some of them made important contributions to the process of developing a proper CVS replacement). And Subversion is just a demonstration of a wrong approach to the problem from the beginning, not worth of trying to use it at all, despite many people like it.