So you want to start using version control software, and in particular you’re interested in Git. Great! There’s a bit of a learning curve, but it’s well worth it. I’ve collected the following suggestions and resources to walk you through the process somewhat. This guidance is oriented toward using Git from the command line, not a GUI. It’s best to be comfortable with the command line Git utility, because that will translate to work anywhere, while any specific GUI program will not be available everywhere you might use Git.

Step 1: Understand what version control software is for

Before you start using Git, it’s important to have a rough sense of what version control software does and what you should hope to achieve by using it. This will help you understand the technical details later, as well, as you can then fit them into a big-picture view.

  • A Visual Guide to Version Control — Provides motivation for why we want to use version control software at all, and follows with a good, clear overview of the most important terms and concepts. It introduces concepts using Subversion, an alternative to Git, but the concepts are nearly all applicable to Git. You can ignore the example svn commands, as we won’t use svn. Read through to familiarize yourself with some of the version control concepts and terminology; it will become clearer with practice. Note that any place it says “check in,” we’ll call that same concept a “commit.”
  • Why you should use version control for yourself — Read the question and the first answer, at least, to get some ideas on how version control will help you even if not using it to collaborate with others.

Step 2: Install Git

Mac

On a Mac, Git may already be installed, especially if you’ve installed Xcode. Try running git on the command line, and if you get a “Usage” message with a bunch of git commands listed, it’s ready to use.

If Git is not already installed, instructions to install it should show up. Follow the instructions to install the “command line developer tools.” You do not need to install all of Xcode itself.

Windows

In Windows, if you don’t have Git already, download and run the appropriate installer for your system from https://git-scm.com/.

During the installation, set the default branch name to main: Git Windows install screenshot 1

And set the default git pull behavior to be “Only ever fast-forward”: Git Windows install screenshot 2

The installer will install Git along with a command line shell called “Git Bash” from which you can run Git commands.

If you are already using WSL2, MSYS2, or Cygwin in Windows you can use Git in that environment without downloading and running the installer above. You can install Git based on which environment you’re using:

  • In a default WSL2 setup: run sudo apt install git
  • In MSYS2: run pacman -S git and pacman -S openssh if you haven’t already.
  • For Cygwin, you’ll need to run the Cygwin installer again. The “git” package is found in the “Devel” category.

Step 3: Make sure you know command line basics

To use Git on the command line, you need to know at least the basics of navigating and using a command line shell. We’ll use a Unix shell here, so work through at least one tutorial from Unix and the Command Line. At a minimum, work through sections 1 through 3 of Software Carpentry: The Unix Shell (up through “Working With Files and Directories”).

To access a command line shell on your computer to practice:

  • On a Mac, use the built-in “Terminal” application. (Quick access: Press Command ⌘+Space, then type in “Terminal” and hit enter.)
  • On Windows, use the “Git Bash” program installed as part of Git for Windows. (If you’re already using WSL2, MSYS2, or Cygwin, you’re already using its terminal, which will work, too.)

Step 4: Learn the basics of Git

It’s always good to start with a guided tutorial to walk you through the initial steps:

  • W3Schools: Git Tutorial — This is a decent intro to using Git for a beginner. Read and work through the first whole section up through “Git Branch Merge”. You can skim through “Git Branch” and “Git Branch Merge,” but you should read and work through them carefully before you start making branches later. Two important notes:
    1. The git init step is needed in this tutorial to create a repository to practice in, but it is not something you should regularly use. Typically, you will be cloning existing repositories rather than initializing new ones with git init.
    2. The tutorial uses the --all option for git add, but you really shouldn’t. It will often add many files to your repository that you don’t want in there. Always specify only the files you want to add.
  • Learn Git Branching — An interactive tutorial (you run and test the commands directly in your browser) that shows you the data structures for the commit DAG as you run commands to create it. The first three tutorials are sufficient for a first shot at using Git in a collaborative project. Read everything with the goal of understanding what the commands do and when/why you use them.

Step 5: Use Git!

Dive right in!

See A Git Cookbook for a quick reference on common tasks.

References

Longer-term, you’ll want to have a few good references to read up on particular concepts as needed. I recommend the following:

  • Pro Git Book — If you want to really be competent with git, read this. It is good. It explains concepts well.
    • In particular, I highly recommend reading Chapter 3, which explains branching and merging. Read it both to understand how the “branch,” “switch,” and “merge” commands work and to see how they can be used effectively.
  • Git for Computer Scientists explains the data structures behind a Git repository, which can really help understand what each command is doing. (This is a perfect example of learning about the details hidden underneath the level of abstraction you typically use in order to be better able to operate at that higher level.)
  • A Visual Git Reference is another nice set of visualizations of Git repositories and the effects of different commands. Very helpful.

Step 6: Add other tools

Once you’re comfortable on the command line, you can use a visual front-end to view and navigate commits, branches, and tags. The command-line tools can do anything you need, but viewing and navigating the commit log is one case where a GUI is probably going to be faster. Git interfaces are often built into programming text editors and IDEs these days.

There are also several standalone GUI programs you could try, many free and open-source. I like gitg for Linux. SourceTree is a good option for Windows or Mac. And Github Desktop is decent, but it is somewhat tied to Github (which is not the same as Git itself and not the only way to host remote repositories). Play around with a few to find one that you like. If you use an IDE, it will probably have a graphical interface to Git built-in.

Many of the front-ends can also help with staging complex commits — those in which, perhaps, you only want to commit some of the changes in a file but not all. I’d stick with the command line for most commits, but a front-end could be useful for things like that.

In any case, it is well worth practicing and becoming comfortable with Git on the command line, because that is the lowest common denominator that will always be available for interacting with a Git repository. If you learn how to use a particular GUI but don’t know how to use the command line, you will be stuck whenever that particular GUI is not available.