1. What is Git?

1.1 Version Control System (VCS)

  • Version Control is a system that manages changes to computer programs, documents, websites, databases, etc.
  • Most VCSs think of the information they store as a set of files and the changes made to each file over time.
  • This is commonly described as delta-based version control (focused on differences between versions).

1.2 How is Git different from other VCS?

  • Git thinks of its data more like a series of snapshots of the filesystem.
  • With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
  • To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored.

  • The table below summarizes the main differences between common VCS (Perforce, CVS or Subversion, etc.) and Git:
Common VCS Git
- delta-based version control - a stream of snapshots
- requires connection to databases or other computers on the network to access certain files - everything is stored locally
- allow limited operations without server connection - nearly every operation can be done locally

1.3 The 3 stages of Git

  • Git has three main states that your files can reside in: modified, staged, and committed:
    • Modified means that you have changed the file but have not committed it to your database yet.
    • Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
    • Committed means that the data is safely stored in your local database.
  • This leads us to the three main sections of a Git project: the working tree/directory, the staging area, and the Git directory.

  • The basic Git workflow goes something like this:
    • You modify files in your working tree.
    • You stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.
    • You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

2. Creating a Git Repository

2.1 Initializing a repository in an existing directory

  • First, you need to open the command line prompt and navigate yourself to the directory you want to create the repo with.
    • For example, it might look like this:
# macOS
cd Desktop/stat430/my-project
# Windows
cd Desktop/stat430/my-project
  • Then, run the following command:
git init
  • The above command creates a new subdirectory named .git that contains all of your necessary repository file.
    • Note that at this point, nothing in your project is tracked yet.
  • If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit.
git add -A
git commit -m "initial project version"
  • Now, we need to connect it to GitHub (at this moment, your repository only exists locally):
  • To do this, we have a choice between GitHub and UIUC CS GitHub Enterprise
  • Create a new repository, then copy the URL (with .git at the end) provided after the repo is created.
  • Go back to your command line prompt:
git remote add origin <your repo URL here>
git push origin master

2.2 Cloning an existing repository

  • We’re very familiar with this option as we did this for our very first lab!
  • To clone an existing repo, use the git clone command:
git clone <url>

3. Recording Changes to the Repository

3.1 Checking the status of your repository

  • The main tool you use to determine which files are in which state is the git status command.
  • If you run this command directly after a clone or after pushing to the remote repo, you should see something like this:

  • Now, let’s say you make some changes, for example, I will add a file called test.md to this directory: