Make SCM tool Git the easiest part in a DevOps transition

Adopting Git as the SCM tool of choice is one of the first steps organizations make as they embrace a DevOps transition. Here, we describe five key ways that using Git differs from traditional, centralized source code management tools.

Many organizations, as they adopt a DevOps-based organizational structure, are moving away from centralized source code management systems, such as SourceSafe and Subversion, and are instead embracing software configuration management tools based on Git, with offerings such as GitLab and GitHub being two of the most popular. Few organizations regret moving their source code into Git, but for those coming from other version control systems, there is a bit of a learning curve. Here are five key points to remember if you are switching over and using Git-based tools for the first time.

1. It doesn't have to be distributed

You can download and install Git onto your local machine. And using either a command line or a plug-in, such as EGit for the Eclipse IDE, you can commit code, create branches and merge code into the development stream, without having to interact with any other developers. Git is known for its ability to facilitate distributed development, but a single instance installed on the local machine, with only one developer using it, is a valid case for using Git.

2. Everything is available locally

When you join a project that uses Git, you will either clone or fork an existing repository. Doing so not only downloads all the code for the project onto your local machine, but it also brings in every commit, revision and branch associated with the project. The project's history resides on your local machine, so if you want to see how the project evolved, how various bugs were fixed or how certain features were enhanced, it's just a matter of moving to older branches and previous commits. The entire history of the project is sitting right there in your forked repository.

3. Branches are your friends

In some SCM tools, branching the master stream is an expensive step, which  can cause a great deal of confusion with developers. Nothing could be further from the truth in the Git world. Any time a developer wants to add a feature, fix a bug, play with your continuous integration configuration or just play around with the code base, they are encouraged to create a branch. If the changes are good, they can easily be rolled into the master branch. If the changes are less than stellar, the branch can be either deleted or ignored. Either way, as long as the changes aren't merged into the master stream, there is no negative effect on development.

4. Clone the familiar, fork the unknown

When obtaining a copy of a Git repository, sometimes, the option exists to clone; other times, the option exists to fork. On projects where you have read and write access, and have the ability to save changes directly back to the repository you are copying, cloning is the option to take. When you are copying a repository, but you don't have commit rights, the approach to take is to fork it. Changes you make can then be made part of a pull request, where a user who does have rights can vet your changes and choose whether to commit them or not.

5. Get a distribution

When it comes to distributed development, using a Git-based repository is an absolute must.

Git is nothing more than a SCM tool that allows teams to check code in and check code out. The facilities it provides to allow for branching, or to allow merging and rebasing, are pretty cool, but fundamentally, Git itself is just an SCM tool. But to truly embrace a DevOps world -- not to mention manage a team of distributed developers -- organizations need other tools that integrate with their Git repository, such as bug trackers, file-level security, team collaboration tools and even hooks into continuous integration tools, such as Jenkins or Hudson. Git-based distributions, such as the ones offered by GitLab and GitHub, provide these types of enhancements. A distribution, along with all of the additional tools they provide, can make moving to Git a much easier transition than if you work with a Git installation alone.

When it comes to distributed development, using a Git-based repository is an absolute must. And not only does a Git-based repository make distributed development easier, but the ability to create branches and even fork repositories allows people outside of development, such as operations people doing builds or preparing for deployment, to play with the code base without fear of doing any harm to the project. For organizations trying to make DevOps a reality, keeping these five points in mind will greatly simplify the transition to Git.

What challenges have you faced when changing from your existing SCM tool to Git? Let us know.