I’ve been using Git since slightly before it became very popular about two years ago. Nowadays it is very popular, with much thanks to github. However, even semi-famous programmers like Jeff Atwood don’t really understand what it’s all about.
I think the primary thing that confuses people about Git is that it assumes that if you are developing software on a team, that you actually talk to people. Whether it’s by IM, IRC, a web site, Twitter, Git doesn’t care. It just assumes that you actually have some form of regular communication with the other developers.
You see, the non-distributed version control systems do not make this assumption. If you are using subversion, your work flow is dictated by the limitations of the software. You do some code. When you commit, you also share. Everyone commits to the same place.
With this sort of system, you don’t need to talk to the other developers to know what to do. There is only one canonical current version of the code in one repository. If you do an svn update, you know everything you need to know. If you change the code, you just commit, and you don’t need to tell anybody. They will see your changes when they eventually do an svn update.
This system inevitably leads to the many problems that Git solves. The one I always like to point to is the situation where you need to make a quick bug fix while you are in the middle of working on a big new feature. You need to make a version of your code that has the fix, but not the new feature. If you committed the feature, it’s going to be a nightmare to get a version of the code without it. If you didn’t commit the feature, it is very hard to collaborate with others. Branching solves it, but branching in subversion is slow and difficult, and it’s shared. You might ruin everyone else in the process.
Git lets you do absolutely anything that is possible to do with your code. You can branch, tag, commit, share, patch, and unpatch your code any which way you can imagine, and some you can’t yet imagine. As long as you are aware of all the commands and features, you can never dig yourself into a hole. You will always be able to deliver the code with the combination of patches that you need.
The problem with this is that since you have so many capabilities, there is no dictated work flow. Should you have a central repository? Should you push back and forth between individual developers? Should we have any shared branches? Should we use tags? Should you use soft tags or hard tags? Should you merge? Should you rebase? All of these questions, and more, are the subject of much debate.
I think that all of these debates are silly. The correct answer is that there is no correct answer. All of the features of Git are just tools to help you get your code the way you need it to be. If rebasing saves the day, then rebasing is awesome. If sending patches by email works for you, then that’s also awesome. Whatever process you come up with for your team to work together on the same code is fantastic, if it works for you.
Even if you decided to follow a subversion style of development, you can absolutely just do it with Git instead. Git can work exactly the way SVN works, if you wish it to. The best part is that you can use it exactly like SVN, but because it is Git, you can escape the usual SVN traps when they come up. Therefore, I see absolutely no reason for a new project to use SVN when you can simply use Git and have developers agree to work in an SVN flow.
And that is the beauty of Git, is that it lets you come up with your own process. How you work is no longer dictated by the limitations of the software you are using. It is decided by the developers themselves. And even if developers like to work differently, as many do, they can each work in a way that is comfortable for them without interfering with anyone else. As long as the team communicates with each other, and agrees on how to share code, all is well.
Just to drive the point home, Git was made by Linus Torvalds to use for developing the Linux Kernel. How do you submit a patch to the kernel using Git? You put your patch up in your Git repository, and you email someone requesting them to pull the patch from you. Email!? With SVN you just commit, no need to talk to anybody. I don’t know about you, but do you think that forcing code changes on other developers without having to talk about it a good idea?
If you actually bother to talk to people then 500+ forks is not a problem. You ask someone and they tell you what fork to clone. Just ignore all those graphs, they mean nothing.
However, I must admit that the 500+ forks is indeed a symptom not of Git itself, but github’s design, and users not understanding Git. Github makes the fork button very prominent, but forking a project on Github is not really something that people should do that often. Github is not Git. The design of Github, intentionally or unintentionally, leads users into doing something they don’t actually want to do. It doesn’t really help people understand Git, and it doesn’t help people communicate.
What most people should be doing is just cloning repository to their local machines, and making changes there. If they want to submit the changes, then they should use non-Git communication tools to talk to the person they cloned from. They only need to fork on github if they want to publicly share changes that have not yet been, or will not be, merged into the actual project. Otherwise, they should not fork, just clone.
If you do have changes that are not accepted, then sharing them publicly on github in a fork is a very useful thing. Maybe there is someone out there who needs a copy of djata with a slight tweak, but someone else made the tweak already. The tweak may never be accepted to the canonical codebase, but it can still be made available in a form. That might save someone the time of making that same tweak themselves on their own, which is what they would likely be doing on a project managed by subversion.
Right now I see people with SVN mindsets who won’t switch to Git because they don’t truly understand DVCS. Likewise there are people with SVN mindsets who don’t understand DVCS who switch to Git anyway for whatever reason. The missteps of the latter group provide many of the stories that will keep the former group scared away.
All in all, I’m not too worried. When I was in college, less than a decade ago, the CS department taught us RCS and the software engineering department taught us CVS. In my senior years some people starting using SVN, which was bleeding edge at the time. Git was released in 2005. The world of version control moves surprisingly rapidly. I think Git’s dominance is pretty much guaranteed at this point. It will just take time for programmers to escape the SVN mindset and understand the, admittedly more complicated, DVCS world.
We Git users are here to help, so ask before you run away or jump to conclusions.
