Adopting the the collaborative git platform, reduces many of the pains of software development, and ultimately gives your team a competitive advantage. Companies and organizations ranging from the likes of Nordstrom, Zillow, and Orbitz to NASA have adopted git for their software development. But moving to git can be a real pain, so after our team made the transition we came up with five tips to ease the initial learning and migration pains teams often experience on the way to becoming a more productive and efficient development team.
But first–what exactly is this git you’ve been hearing your developers rave about? Git is a free and open source Distributed Version Control System that allows teams to collaborate on software projects of all sizes. Its core functionality helps track code changes, tag and manage your releases, as well as share and store software repositories in a distributed fashion.
Git is the next generation contender of traditional version control systems like Subversion, CVS, Perforce, or ClearCase, that’s quickly becoming the de-facto standard for modern source code collaboration. Its popularity stems in part from its ability to dramatically improve several areas of the software development process. Examples include:
- Gaining a tangible work-speed boost thanks to local clones, powerful context switching capabilities, and the raw speed of git.
- Freedom to implement different workflows, feature-based development branches, simplification of integration, and release management to smooth out rough edges for the entire team.
- Core security features like cryptographically validated chain of commits, commits sign-off, and release signing that lets IT and ops teams sleep soundly.
- Git, the technology, also has huge open source mindshare.
But everything that changes the old way of doing things comes with pains inherent in innovation and learning. How can you move through the adoption phase and reach full productivity in the shortest time?
- Lay out a migration plan using small steps.Git brings to the table many new concepts and capabilities. Naturally, those take time to be absorbed and adopted proficiently within an organization, so take a gradual approach.
- Start by cloning the repository into git, but keep everyone working on the older system.
- Later, transfer your continuous integration and deployment setup to the git remote repository while developers keep working on the old version control system.
- Finally, switch developers’ daily work to the new git repository. Jonathon Creenaune explained this process extensively.
- Start from a familiar workflow, then evolve it:Start with a workflow similar to your current process. If your team is used to committing everything to the trunk, have them commit their fixes to the equivalent git branch (master) and wait before adopting a more advanced branching model. After the team is comfortable with the basics, incorporate bits of process innovation like feature-based development, where each new feature or bug fix gets its own branch. Then, start requiring pull requests as a low-friction code review step.
- Make your life easier with awesome tooling: Migration tooling has evolved. You can certainly use the basic git-svn command to perform the first conversion to git, and here is some very detailed migration info for this. Just keep in mind that the initial checkout/clone process can take a long time if you have a history that spans years. For example, migrating our JIRA code-base from Subversion to git using git-svn took three days. More recently, tools like subgit have emerged to simplify the process of migrating from Subversion to git. I encourage you to have a look.
- Have a champion:It helps if one or more colleagues are “Git Champions”, or people already familiar with git who can be a resource during the initial months of adoption. They can answer basic usage questions, workflow questions, notify the team of cut-over dates, and give hands-on demonstrations. For context, empirically acquiring the new mental model and a good level of proficiency took our teams between two to six weeks, and having a champion helped us in that transition.
- Tweak workflows to increase your efficiency:Choose a branching model that matches your software business. If you have regular product releases and need to maintain older legacy versions, keep the master branch in an alpha state and maintain several stable branches. If you have a continuous delivery setup, then keep master as your production branch and keep a long-running development branch where all planned features are branched from. Also, consider whether you want to work with a single central repository or if you want to adopt forks. In general, a single repository is easy to work with, and provides most of what a team needs, but there are situations where forks might be useful. Why fork? Because you can guard core components but encourage innovation and adoption, organize cross-department collaboration and streamline interaction with external contractors or developers.
Sometimes just making the decision to adopt a new technology is the hardest part. With git, you can start with a project before migrating a whole code base giving your team the opportunity to see all the benefits of distributed version control before moving all your projects over. It’s worth the test.
Giancarlo Lionetti is a group product manager for developer tools at Atlassian.
Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.
- The new building blocks for IT: OpenStack, continuous delivery, and devops
- How devops can reduce cycle times
- What’s next in the world of software-defined networking