Migrating to Git, Part 1: Advantages
September 9, 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.
Three advantages of Git over SVN
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?
1. Stability of shared repositories
- SVN: All developers commit work-in-progress code to shared repositories
- Git: Developers commit code to local repositories first
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?
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.
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.
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.
- SVN: Developers often perform bulk commits towards the end of feature development. Work-in-progress code is often left un-versioned to avoid negatively impacting the rest of the team.
- Git: Branches are created and destroyed rapidly and locally to support new features or experimental code. Local branches are pushed to various remote repos for team collaboration. The risk of un-versioned code is severely mitigated with private repositories and the ease of pushing branches to shared servers.
Why does this matter?
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.
Process and workflow
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.
3. Task switching
- SVN: Switching between branches is painful. It’s essentially like copying and pasting an entire directory structure and having multiple local copies of your project.
- Git: Git handles switching branches by simply updating the contents of a working folder with the contents of the branch you specify. There are no folders to duplicate or other steps that impede your workflow.
Why does this matter?
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.
To be continued
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:
Migrating to Git, Part 2: Prerequisites
Migrating to Git, Part 3: Moving your code to Git