Welcome to Yet Another Post About So-Called Killer Features of Git. Of course, I'm not the first who writes about it. No wonder: Git already was in a good shape in 2005 (link). However, in my opinion, some people seem to misunderstand why Git's killer features are important in everyday work. I'll cover my thought on that it in this post.

If you still don't know, Git is a fairly recent source-control system that was originally written by Linus Torvalds. That tells a lot about it; I already see scared corporate clerks, who convulsively close the browser tab. So, what can Git propose to more advanced developers?

1. Distributed all the time

Many people say that the main feature of Git is that it's a distributed source control system. That's not a killer feature, it's "just" a different workflow, different approach, different philosophy of version control.

And the direct consequence of it is the aptitude to work without connection is not a feature. What is a feature is the necessity of such behavior. Let's look closer at usual workflow:

git add ...
git commit
git add ...
git commit
....
git push

At first, you have to manually pick what files the next commit will consist of. You do it with various forms of git add. Is it a feature or an obstacle? I think it's a feature. I saw it many times when people commit the stuff that belongs to their local machine, because Subversion just commits everything that changed upon running svn commit. With git add you have to select what you add manually. Slow? Perhaps. But it is the usual workflow, which requores you to treat commits as serious actions, and I'm really tired of those bad commits that bring stuff that doesn't belong to them.

Okay, so you've made several commits. Guess what you now have on your hard drive? You have a draft of a repository (so-called "index"), which you're going to replicate to main server only when you invoke git push. You don't have to--and should not--push your changes at once. Instead, you now can test each of your commits, you can checkout from that folder! At work my test system is tuned to do exactly this: checkout from local repository and run regression tests.

If you feel that your draft contains errors, you have built-in Git features to bring your repository draft to a good shape. You can fix comment of any of your new commits, you can change their order, you can rollback several commits and merge branch as if it was merged several commits ago. And only then you git push the changes thus merging with repository on the server. Of course, if you're not careful, you're shooting yourself in the foot, just like in C, with which Git really is indeed compared. But still, I think it looks way safer than what you can do with Subversion, where each your commit is pushed at once.

2. Branching

Git can have lightweight branches! It can store hundreds of branches on the server without significant time overhead! Wow!

That's what they say. But it's not really important. The important thing is not that you can commit them to server. The thing is that you may not commit them, and store these branches locally. On my machine I have about 10 branches, only one of which is synchronized with the server. I can merge this branches the way I want, I can checkout any of them to test them locally. And all of these things I can do without bothering our centralized repository.

Another killer feature related to branches is the ability to switch branches within one directory. No wonder it's possible: you have a repository within it anyway. And it's really helpful; I still remember that hell when I had to branch Bazaar by checking it out to different directories. It's a hell I'm never coming back to. This strict, seemingly clean structure "one folder for one branch" just doesn't work well.

And here's the third feature...

3. Flexibility

"Git is the C of Version Control Tools", says Eric Sink, the 5th google result for "Git killer features" request. Yes, it's true. And it's useful, because others may write front-ends for other repositories. git svn is a well-grained tool that allows you smoothly integrate with Subversion.

I wrote an answer for a question "Why not use git?" by just observing my colleagues. They just didn't know how to use it, and even didn't want to try first. And it happened this way: I used git, they used Subversion, and we all were happy. You won't be able to merge Subversion branches with Git's native mechanisms (SO question), and you will encounter a bug that won't allow you rename files (git svn doesn't handle this case: you should first commit deleting files, then commit adding new files). But I think that working with Git worth all these obstacles.

Conclusion

If you liked it, use it! You don't even have to persuade others to use it, just install git svn (if it's not integrated) and you and your team will all be happy. Git's cool; don't be a corporate clerk, try and use modern and flexible tools, when they're available.

Comments imported from the old website