An introduction to Git

  • Software Engineering

A short introduction and tutorial to Git, the versionning tool created by Linus Torvalds.

Some History

Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development. Its current maintainer since 2005 is Junio Hamano.

The name “git” was given by Linus Torvalds when he wrote the very first version. He described the tool as “the stupid content tracker” and the name as (depending on your way):

  1. random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of “get” may or may not be relevant.
  2. stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
  3. “global information tracker”: you’re in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
  4. “gddmn idiotic truckload of sh*t”: when it breaks

Source: Wikipedia

First Steps

Install git

sudo apt-get install git

Configure git

git config --global "John Doe"
git config --global ""

Init an empty repository

mkdir lab-git && cd lab-git
git init

… Or clone an exisiting one

git clone git://

Create a file


So far we have:

  1. A local git repository
  2. A file that is not being tracked

What we need to do:

  1. Tell git to track the file
  2. Create a remote repository to store our code
  3. Push our code to the remote repository

Tracking a file

git status # our file is untracked
git add
git status # our file is tracked!

Setting a remote repository

Usually done through websites like github, bitbucket, gitlab.

Once a remote repository is created, we are provided its url. Then, tell the local repository what its remote url is.

git remote add origin # origin is our remote name
git remote -V # verify the remote

Commit and push to the remote repository

Even though we tracked our file, we didn’t commit anything. When commiting, we provide a message explaining what we changes within the tracked files.

git commit -m "started tracking"

Now, we commited our change. Although, everything is still local, nothing is published on the remote repository yet. To do so, we must push our last commit.

git push origin master # push to the branch master on the origin remote repository

To get the latest changes on remote, use pull command.

git pull origin master

Additional useful commands

Display last commits

git log

Display what has been changed since the last commit

git diff

Cancels all local changes and rolls back to how the file was at latest commit

git checkout

A visual recap



Collaborating with other people

Common configuration

n co-workers, one repository, one production server.

Co-workers work on the same project and can edit the same files simultaneously. Updates are pushed on the distant repository, and pulled from the production server.


NEVER EVER commit, push or edit anything on the production server.


Branches allow people to work on separate tasks without messing with the master branch code. It is useful to experiment, or add functionalities. Branches can start from the master branch, or from another branch.


Source :

Check branches within local repository

git branch

Create a branch named awesome-feature from the active branch

git checkout -b awesome-feature

Edit some code, add and commit files. Then push them to the remote server, but not on master.

git push origin awesome-feature # create branch on the remote repo

Delete local branch

git branch -d awesome-feature

Merging and pull requests

When we are finished working on our feature-branch, we must check for conflicts before pushing to master. To do so, pull the master branch into your branch, and fix your conflicts locally.

When all the conflicts are resolved, push again, still on your branch, to the remote repository. Then, make a pull request, that will eventually get merged on the master branch by the repository administrator.

More useful tools

Stash your local changes

When your git pull fails because you are editing a file that has been changed by someone else, temporarily stash your changes, pull the recent modifications, then apply your changes again.

git pull origin awesome-feature # fails

git stash # stash changes
git pull origin awesome-feature # works but your changes are temporarily gone
git stash apply # re-apply your changes
git commit -m "made the world a better place"
git push origin awesome-feature # now the world really is a better place

Ignore unnecessary files

Please never add anything other than code/configuration files in a git repository. This is not Google Drive.

Create a .gitignore file at the root of your repository, with the following content:


This tells git to never track .pyc or .csv files, because who needs to ?

You can also ignore entire directories. You should avoid using git add * if you’re not sure you’re ignoring unnecessary files.

Remove files on the repository

What if you no longer want to track something ?

git rm # will also delete the file from your disk
git rm --cached # will only delete on the remote repository

Versioning configuration files or critical files

Sometimes you want to track files that contain passwords, or configuration variables. Those files are likely to change independently from the code, so you don’t want to commit every single change in those. They might also contain sensitive information that you don’t want to store within the repository.

What you should is tracking a .dist version of the file that has all the required fields, but without any value.


If you are refering to a conf file named variables.env, name you dist file variables.env.dist. Track the .dist file, but ignore variables.env.

Every repository should have a decent file, explaining what it is about, and how to configure and install the dependencies to start the application. This file is written using the Markdown syntax. You can read about it and have look at this cheat sheet to get started.

Go ahead and do this tutorial if you have 15 minutes to spare: