Skip to end of metadata
Go to start of metadata

Git is a version control system for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development, but it can be used to keep track of changes in any set of files.  We maintain all software code, scripts, and TeX documents (e.g. theses) in a git repository. Git is easy to learn and will help you in many ways, making your coding and writing more effective and easier.

As a distributed revision control system, it is aimed at speed, data integrity, and support for distributed, non-linear workflows.

As with most other distributed version control systems, and unlike most client–server systems, every Git directory on every computer is a full-fledged repository with complete history and full version tracking abilities, independent of network access or a central server [1].

Why use Version Control?

Several reasons:

  1. Collaboration: All users in a project use a common shared repository. This is especially important for coding or writing documents. Instead of e-mailing files and appending version numbers to the filename, all updates propagate to everyone in the project. A good mechanism for collaboration is essential, especially when many people are working on the same project.

  2. Diffing: All users in a project can perform a "diff" to see what has changed. This means that when you update a piece of code, or the text of your thesis, it's easy for everyone (including your thesis advisor) to understand the differences between versions.

  3. Backup: Each revision of the repository represents a snapshot in time. Thus, if you are working on a bit of code and want to get back to an old version with consistent state, it is simple to revert. Similarly, if your computer crashes, all of the data is, inherently, backed up on the server.

  4. Consistency across multiple machines: There is no limit to the number of machines or hosts that have a copy of the repository. This implies that you can work across multiple machines, say a laptop and a home desktop, using them interchangeably while keeping everything consistent.



Git can be a bit confusing to the newcomer, and there is a certain etiquette to using git. Git is not DropBox! Don't worry though, most common tasks in git are simple and easy to learn. Most importantly, your project will benefit from git in many ways.

Do's and Don'ts of Git


  1. Commit early and often: Doing so permits you to "checkpoint" your work, ensures that you stay in sync with others on the project, and provides a backup of your work in case something happens.

  2. Add useful commit messages: You should have a quick one-line summary of the changes in the commit, then a blank line, then a more descriptive narrative or bulleted list describing each change. This will help others know the intent or content of the commit without having to read through diff logs. It will also help you when you're looking back through the logs.

  3. git pull regularly and often: If others are working concurrently on the same project, this keeps you in sync so you don't duplicate each other's work or wind up having to do a giant merge due to overlapping work.


  1. Commit large binary files: Git was not designed to handle binary files and all of its benefits are lost on binary files because it cannot maintain revisions. Avoid committing file types such as:
    .pcap, .pdf, .doc[x], .xls[x], .ppt[x], etc.

  2. Commit the same data in multiple places: This defeats the purpose of a revision control system.

  3. Commit derivative files: For example, a compiled code binary, or the generated pdf of a LaTeX document. So, don't commit C object files (.o). Don't commit LaTeX temp files (.dvi, .bak, .log, .blg, .aux, etc).

  4. Use spaces in filenames or directories: Spaces or other odd characters make life difficult for those using command-line interfaces.

Using Git

This usage guide only covers using the command-line tools. Some GUI-based tools exist as well, such as Tower 2 on Mac. However, we strongly recommend starting out with the simpler command-line tools.

Initial Setup

Install Git client.  This varies by operating system.  For Mac and Linux you should install Git via your preferred package manager (e.g. $ apt install git).  For Windows you can download Git from the website.

Clone repository

Do this first to get a local copy of the repository on your system

  1. Create a folder for the local copy of the repository you are going to clone
  2. After receiving access/user credentials: 
$ git clone ssh://



Show a list of previous commits to the repository

$ git status


Get new commits from the server, that have occured since your last checkout/pull

$ git pull


Add your changes to the local repository.  Requires a commit message.

$ git commit FILENAME -m "Write a useful message about the changes you are committing."


Sends commits you have made in your local repository to the server.  Requires your local copy to be current with the version on the server.

$ git push


Display the commit log for a particular file or directory.

$ git log FILENAME


It's often handy to examine the differences between two versions of a file. To compare current uncommitted edits against the most recently committed version of a file:


Tells git to track changes to new files.

$ git add FILENAME


Stop tracking particular files.

$ git rm FILENAME


Specify intentionally untracked files to ignore using the .gitignore file.  You can add this file to the repository so it will propagate to all instances of the repo.


This list is just the beginning.  This and much more information on Git usage may be found at:

Much of the content here was shamelessly repurposed from the CMAND SVN Cheat Sheet [2].


  1. Git - Wikipedia
  2. SVN Cheat Sheet - CMAND