Introduction to GIT
Updated 2,329 Days AgoPublic
Actions

Version 5 of 15: You are viewing an older version of this document, as it appeared on Dec 20 2017, 16:41.

WARNING: Work in progress

Introduction

GIT is a Version Control System (VCS) for source code created by Linus Torvald (the creator of Linux). It allows to share and collaborate on code efficiently. It somewhat has a diffucult barrier to entry because it's packed with feature. However you can learn a few basic terms and command to use it in an easy way.

Distributed

In opposition ot other VCS (Subversion for instance), GIT is distributed. It means there's no central server and everything you do is happening on your local machine. It also means you can work on your code locally without being connected to the internet and syncronize with a remote server later.

Vocabulary

Here's a list of usual terms you will enconter in the guide, you can refer to it later.

Repository / History: The git history represents your code at different stages in its development, all of this is a repository
Commit: This is a set of patches bundled together with an author name and email at a specific date. The history is composed of a sequence of commits. Each commit has a parent commit forming a immutable history.
Branch: Like a tree branch, a sequence of commits may have diverged from the main (master) branch, usually to develop a new feature that will be merged back to the main branch
Merge: Reconcile two branches by creating a merge commit and resolving potential conflicts (the same line in a file have been edited in both branches for instance)
Local: A repository on your machine is a local repository
Remote: A repository on a server (c4science, github, ...) is a remote repository. A local repository can be bound to multiple remotes at the same time
Working copy: These are the files you see in your machine, it represents the states of your repository at a certain point in time (a commit) and space (a branch)
Index / Staging area: This is a remporary place where you add changes to be commited. Typically using git add <file>. It's usefull to separate the working copy and the staging area in case you don't want to commit every changes

Basic operations

The usual workflow when using git consist of the following sequence of commands:

git clone <URI>
git add <file>
git commit -m "commit message"
git pull
git push

Let's break down every command.

git clone

This retrieve a remote repository on your machine, downloading the complete history of every branches locally. It's actually a wrapper for other commands:

git fetch # gets all the changes on the remote to a local history
git checkout HEAD # create a working copy of the HEAD (usually the master branch)

git add, git commit

You've made some changes to some file in your repository and now you are ready to settle those in a commit.

The first step is to break down your changes in multiple commits if this make sense. For instance, you added feature-1.c and fixed a bug in main.c. You'd want to have two separate commits so it's easier to review by your peers. You can then do the following:

git add feature-1.c
git commit -m "Adding the new feature 1"
git add main.c
git commit -m "Fixing a nasty bug in main.c"

The result will be two separate commits, each one contains the corresponding patch.

commit 88c8976e60297890060c7ab579a5044833352645
Author: Jean-Baptiste Aubort <jean-baptiste.aubort@epfl.ch>
Date:   Wed Dec 20 16:34:34 2017 +0100

    Fixing a nasty bug in main.c

commit 7edcd6aae67a3d05cd5b3b5b9d2bfbf5f3d33371
Author: Jean-Baptiste Aubort <jean-baptiste.aubort@epfl.ch>
Date:   Wed Dec 20 16:34:27 2017 +0100

    Adding the new feature 1

git pull, git push

Those commands let you interact with the remote repository (c4science). You can either pull the new commits from the remote or push your new commits to the server.

It's always a good idea to pull first because git will not let you push if there are new commits on the server that you don't have on your local copy. You are then in charge of integrating those new commits by merging, and potentially fixing some conflicts.

Conflicts can happen if the remote and local commits modify the same portion of code, a human then have to review both changes and fix them manually. If the changes are in distant portion of code, git can automatically merge the changes without conflict.