9th of September, 2012
Git is unlike typical version control systems. Sure, Git is used to version files, but how is that any different than SVN or SourceSafe or ClearCase?
Git expects developers to understand how it works under the hood. It expects developers to be comfortable with the command line to get the most out of it. It provides very little in the way of convention and expects you to design your own workflow simply by using it as another tool in your arsenal. Git is not an out-of-the box solution. If you plan to transition to Git you also need to set aside time to examine your overall development process. You won’t get the most out of it otherwise and will possibly experience a challenging migration.
Doesn’t that sound dreamy?
Before you become discouraged, let me explain that Git is not only a version control tool. It’s also a development workflow design tool, it’s a quality control tool, it’s a productivity tool.
Git is simply one of the best things that’s happened to the development workflow in a very long time; if you choose to master it. If you’re not willing or able to put in the amount of time needed to properly learn a new tool and are simply looking for a place to dump your code, stick with your current VCS or consider migrating to something other than Git.
SVN is a centralized version control system (CVCS). Git is a distributed version control system (DVCS).
What’s the difference between a CVCS like SVN and a DVCS like Git?
Local repositories are later synced with shared repositories. The workflow looks like this:
clone > pull > add > commit > push
Until a git user executes a push, commits are kept safe and sound in their local repository.
Why does this matter?
Speed. Developers using Git commit freely as their work does not immediately impact the rest of the team. They experiment in branches, committing code or stashing changes throughout the day. Nothing is permanent and every mistake can be reversed without impacting the entire team. They can throw everything away and start from scratch if necessary. Not only that, but Git commands are blazing fast because they don’t involve network traffic to a centralized server. Only fetch, pull, and push involve any network traffic. Every other command operates on the user’s local repository.
Confidence. The Git workflow removes fear and builds confidence. Over time a team is more and more willing to take on work they may have deemed too scary when using a VCS like SVN. Why is this? They don’t need to struggle between the lesser of two evils: not committing code, or sharing code that isn’t fully tested. Git lets a developer have the best of both worlds; keeping their code in version control, and only sharing changes when they are ready to be pushed to the team. It’s nice knowing that your code is safely version but that you are not permanently impacting your team if you make a mistake.
Collaboration. One may argue that collaboration is hampered because code is kept in local repositories until finished or stable. Keep in mind that nothing stops multiple developers from remoting to each other’s repositories to share work-in-progress code. Other options for collaboration include pushing work in progress code to a code review repository before pushing it to a stable, public repository. Collaboration options are limited only the imagination of your team.
Why does this matter?
Integration. Developers using Git don’t impact the entire team with individual commits being shared before an entire story (or feature) is stable and tested. Developers create branches and merge changes when a feature is ready for integration. Branching is possible with SVN, but it isn’t used in the same fashion as in Git, because branches in SVN are expensive to create.
Productivity. Git is just as much a workflow tool as it is a source control tool. Rapid branching makes working on more than one feature an incredibly flexible process. Merging in SVN is often a nail-biting experience because it’s such a potentially destructive process. By contrast a developer using Git can create a new branch, merge multiple branches into it, resolve conflicts, and test locally before squashing the individual commits and integrating it with a main release branch. The worst case scenario in Git is starting over again locally without any impact to the team. The worst case scenario in SVN is corrupting the central repository and getting fired.
Developers using Git simply commit (or stash) their work-in-progress code and checkout the alternate branch they’d like to work on. Their working directory is updated in place with the correct code and they continue to work uninterrupted. When they finish their task they simply …
pull > commit > push > checkout
… the previous branch they were working on.
Are you excited about Git? I am, and so are a lot of other developers!
If you’re interested in learning more about the tasks involved in migrating to Git, please read the next two instalments of my Migrating to Git series: