Git at VTC

This document describes how to get up and running with the Git version control system. It is intended to support my students at Vermont Technical College and does not cover all (or even most) aspects of Git.

Installing Git

If you are using HackBox you do not need to install Git. It has already been installed on that system. If you are using Windows you should download Git for Windows. Accept the defaults when installing. In particular, only use Git from the provided bash shell and let Git do CR/LF translations. This is the least invasive configuration, and it also allows you to interoperate cleanly with Linux/Unix users.

One-Time Setup

If you plan to make any commits (and you probably do even if you don't think so right now) you should configure Git with information about your identity. At the prompt (Windows users open the Git bash shell) issue the following commands:

  $ git config --global user.name "Jill Jones"
  $ git config --global user.email JJones@vtc.vsc.edu
  $ git config --global push.default simple

The first two commands store your user name and email address into your personal .gitconfig file (in your home directory on Linux or in your profile folder on Windows). These "global" settings apply to all your Git projects unless you override them with repository specific settings later. Be sure to type "user.name" and "user.email" literally. They are configuration keywords, not something you should fill in. However, provide your real name and address at the end of each command.

The third command sets the default push mode. If you don't specify anything Git version 2.0 will use "simple" by default anyway. However, earlier versions of Git use a different mode by default. By explicitly setting push.default to "simple" you ensure consistent behavior regardless of which version you use (and you probably want "simple" anyway).

What is Git?

You are now ready to use Git. But what is Git, exactly? Git is a distributed version control system. Let's briefly review what that means.

A version control system tracks previous versions of your files and helps coordinate changes made by multiple developers on the same set of files. Every version control system makes use of two main components. The first is a repository that stores all versions of all files along with historical information about them (when changes were made, what was changed, who did the change, etc). The second is a working copy that contains a view of a particular version of the repository.

Version control systems allow you to create branches of development where you can make changes to files in an exploratory way without disrupting the main line of work. Thus a working copy is a particular version (usually the most recent version... referred to as the "head revision") of some branch. In Git terminology the main line of work is called the "master" branch.

With a centralized version control system the repository is kept on a server and each user checks out his or her working copy from that server. When a user makes a change the modified files need to be "committed" to the server so that other developers can see them. This is a fine system and works very well for some projects.

With a distributed version control system like Git every developer has a complete and independent copy of the entire repository. This allows developers to commit changes without being online and also brings some other benefits as we will see. However, developers still need to periodically synchronize their work with each other, usually by "pushing" changes to and "pulling" changes from a special repository that serves as a master for the project.

Using Git

Before you can do anything interesting with Git you will need a repository along with a working copy from that repository. It is natural to clone an existing repository for this purpose. For example you can clone my Hexdump project on GitHub by issuing the command:

      $ git clone https://github.com/pchapin/hexdump.git Hexdump
    

This creates a folder named Hexdump (the last word on the command line) immediately below the working folder where the command is issued. Inside the Hexdump folder is a copy of the repository in the .git hidden subfolder and a checked out working copy of the head revision of the master branch.

Generally you ignore the repository inside .git and use git commands to manipulate it. However the files in the working copy are ordinary files that you can read like any other. Typically you would build the project right in the working copy; don't bother making a copy of the working copy!

When you want to get changes that have been pushed by others issue the command:

      $ git pull
    

from inside the Hexdump folder. This will download changes from the main repository on GitHub and immediately check them out as well, modifying the files in your working copy as appropriate.

The command

      $ git status
    

gives you a short report of the status of your repository and working copy. You can use it to see if there are any modified files that have not yet been committed (for example if you changed a file without meaning to do so). In that case you can revert the modified file to its original state using a suitable Git command.

If you planned to contribute to the project you would make modifications on purpose and the commit them to your local repository. At some suitable time you could then push those changes back to the main repository on GitHub. I don't expect you to be contributing to my projects in connection with your course work. However you may wish to modify files in your working copy as part of your homework assignments, or even just for your interest. To do that I recommend you create one or more branches as I describe in the next section.

Working With Branches

One of the strengths of distributed version control systems are their support for "lightweight branching." It is a simple matter to create multiple branches of development and then later delete them if the work doesn't play out. As an example using Git suppose you wanted to create a branch for homework assignment #1. You might proceed as follows

      $ git branch
    

This command shows you all of the branches in your repository. At first this will likely only show you the "master" branch. The branch that you have checked out in your working copy is highlighted with a '*' character. I use the git branch command often, along with the git status command to just review my current situation.

To create a new branch for homework #1 do something like

      $ git branch hw01
    

You can use the git branch command again to verify that the branch was created. Notice, however, that it is not selected; the current branch in your working copy is still the master branch (as indicated by the '*' character).

To switch to the new branch do

      $ git checkout hw01
    

This rearranges your working copy to match the head revision of the new branch. Since the branch is identical to master when you created it, nothing is actually done this time. However it is now appropriate for you to make changes according the assignment.

If you need to add a new file use the command

      $ git add newfile.c
    

If you need to remove an existing file use the command

      $ git rm oldfile.c
    

You can't just delete a file in the usual way; Git won't know about the removal and will complain that the file is missing (you can restore it from the repository if you delete it accidentally).

When you've reached a natural stopping point for your work you should commit it using a command such as

      $ git commit -a -m "Log message"
    

The -a option adds all modified files (you usually want that) and the -m option introduces the log message. You should provide a good log message that describes the purpose of your change. The log messages become part of the repository history and can be viewed later if you want to find a change you made in the past.

I recommend using the git status command before doing a commit to review which files you've modified and to see if there are any new files that you haven't yet added. The -a option only "adds" modifies files already known to Git. You need to explicity git add any brand new files.

You can make as many commits as you like to your own repository. If you want to return to the master branch, perhaps to review something, just do

      $ git checkout master
    

This will reorganize your working copy to match the master branch. Your changes will vanish... but they won't be lost. You can go back to your work by just doing

      $ git checkout hw01
    

to return to the branch you made. You can even make multiple branches for different purposes but be aware that when you create a branch it will initially be a duplicate of whatever branch you currently have checked out. For example when you create a branch for homework assignment #2 you should probably first check out the master branch to use as a base for the hw02 branch.

Also be aware that if you do git pull the changes from the main repository will be brought into the branch you have currently checked out. You may or may not want that. In general you might also want to check out the master branch before doing a pull.

Finally keep in mind that if you have uncommitted changes when you switch to a new branch those changes will be carried over to the new branch. In most cases you will want to commit all your changes before switching branches.


Last Revised: 2015-01-03
© Copyright 2015 by Peter C. Chapin <PChapin@vtc.vsc.edu>