Overview

Let’s face it, the entire software industry is moving over to git. Open source has already moved. A fairly old, but still interesting, StackOverflow article shows some data on how the open source community has largely moved over to git. You can view the article HERE. The TLDR is this, you need to understand Git.

If your team isn’t already asking for it, they will be shortly. You need to understand what the implications are to your software project, and determine a migration strategy. Also, you need to understand the basic workflow and terminology that Git introduces.

Most other overviews of Git out there get into the weeds very quickly. I’ll try to give you a quick overview, and cover everything that you need to know from a manager’s perspective.

What is Git and how is it different?

Git is a version control system. But i’m sure you already knew that! Git was created by Linux kernel superstar, Linus Torvalds, in 2005.

What makes Git different compared to other popular systems out there, like Subversion or Perforce, is that it is a distributed version control system. This means that instead of there being a central repository server sitting on your local network, each individual developer has a copy of the entire repository (including commit history, changelogs, etc.) on their local machine.

This has the nice side effect of making git extremely fast. Typical operations like branching, diffing, retrieving old commits, etc. are super fast because all the files are stored on your local machine. There is no reason to reach out to a network.

What’s the big deal?

Besides the performance benefits mentioned previously, Git has become very popular because of the advance in how it handles branching and merging, compared to its popular predecessor Subversion. Branches in Git are extremely lightweight. A branch is just a reference to a commit. There’s a great article over on StackOverflow on why Git is so great at merging HERE.

In addition to the benefits of the tool itself, one of the biggest spikes in Git usage has been due to Github.com. Github is a hosting company for git repositories. They cater to the open source community, and host thousands of projects. With a few clicks you can setup a Git enterprise account for your organization, and not have to worry about managing the servers internally.

What’s all the confusion about?

As great as the capabilities of Git are, the learning curve is steep. Git is known for having a pretty terrible command line interface. I have many veteran software engineers on my team with decades of experience, and they all seem to struggle with it. It’s important to be aware of this when choosing how to migrate your organization.

I strongly recommend piloting git on a project that is off the critical path, and with just a subset of repositories to start. This will give your teams a chance to ramp up and learn the tool. Also, you may want to have a training session or have your team watch some videos on the basics. Pick a project that has a very simple repository structure to start. Don’t give into submodules or multiple repo’s yet!

One of my favorite overview videos for software engineers is called ‘Git for ages 4 and up’ and is linked below. In this video the presenter explains how Git works under the hood using tinker toys.

[embedyt] http://www.youtube.com/watch?v=1ffBJ4sVUb4&width=300[/embedyt]

What platforms are supported?

Git pretty much works on all platforms. Linux, Mac, and Windows are a piece of cake. See the installation section below for more info.

How much does it cost?

One of the nice things about Git, especially if you are a startup, is that it is completely free! Git is licensed under GPL.

There are a bunch of commercial tools out there that make Git even easier to work with, but all the basic tools you need are free.

If you are open to hosting your code remotely (this may depend on your companies IT policies, check first), Github is probably the most popular solution. Prices range from $25-$200 per month, depending on the number of repositories.

How do I install Git?

Client

To first start working with git, you will need to install it on your local machine.

On linux, installing git couldn’t be simpler. Just type:

$ sudo apt-get install git-all

On Windows, you’ll have to grab one of the installers HERE. Or, on mac you can get the xcode command line tools, or grab an installer HERE.

That’s all you need to get going!

Server

If you need to set up a git server for your organization, that’s beyond the scope of this article. However, there are many resources out there. You can go the free route, or in my company we chose to purchase Stash (aka BitBucket Server). The nice feature of Stash, besides the web front end, is how well it integrates with the other Atlassian tools, like HipChat and Jira.

Basic Command Line Concepts

Once you have the tools setup, the basic workflow is as follows.

Creating a new repository

To get started, you may want to create a brand new repo, or ‘clone’ an existing one. To create a new repository, simple do the following:

$ git init .

This command will transform your current directory into a git repository. After running this command you’ll notice a new .git folder. The entirety of the repository is stored in this folder.

Cloning

Cloning in git is when you make an entire copy of a repository, usually from a remote location to your local machine. The syntax is:

$ git clone <repo>

For example,

$ git clone https://github.com/facebook/react.git .

This will make an entire copy of the react.js repo on github on your local machine in the current directory. The URL will always end in the .git extension, as this is the main repository file in Git. Once you have the repo, you can start to interact with the repo.

Add/Modify/Commit Files

It’s out of the scope of this article, but the basic workflow after you clone in to modify/create new files in your project, and then commit them to the local repository. If you are familiar with SVN, then the add/modify/commit workflow will be familiar to you.

One very important thing to remember, when you commit to your local repository, there is no interaction with a remote server.

Other Commands

I’ve found that most discussion in my team around git has to do with branching, merging, and rebasing. It’s important to know some of the terminology, so see the glossary below. Also, check out Atlassian’s article on rebasing vs. merging HERE.

Git Glossary

Clone – Making a copy of a Git repository from one location to another, usually from a remote machine to your local one.
Push / Pull – Push is merging code from your local repo to a remote. Pull is the inverse, merging code from a remote repo into your local one.
Pull Request – A pull request is a workflow where a developer is done with a change and is requesting that his code be pulled into the main line. With the GUI tools, this process is facilitated with some form of code review process.
Checkout – This is one term that I found confusing with git for some reason. Checking out basically means you are changing your current directory structure to match a specific commit/branch/etc.
Rebasing – Rebasing is moving one a branch from one base location to another. The Atlasssian tutorials have a great comparison on when to use rebasing vs. merging HERE. The ‘golden rule’ of rebasing is to never use it on public repositories.
Commit – Committing is taking your local file modifications and committing them to the official repository record.
Remote – A remote is a connection to a remote repository. This is usually the public repo that everyone else on the team is working from.
Origin – Origin is an alias for a repository where you originally cloned from.
Master – Master is a branch name, usually the main one that you branch from. Master is equivalent to a trunk in other version control systems.

Additional Resources

The authoritative git book is ‘Pro Git’, which can be found at the link below:

<br />

A free version of the book can be found at: https://git-scm.com/book/en/v2

A couple other books that I recommend are the following: