GIT Tutorial – Basics

Git is a distributed version control system. Distributed means, that each user has a local copy of a (remote) repository on his or her computer. I will dive right into Git using hands-on examples. In this part, I will only focus on local repositories to explain the basics. There are many ways to install git. On MacOSX I prefer using brew:

brew install git

Setting Up a Local Repository

A git repository contains a history of files in your working directory (the directory that is under version control). To put a local directory under version control go into the directory and enter

git -init

Now this directory is your Working Directory and the Local Repository was created. If there already are files in the Working Directory they are not yet under version control. You will have to add them first by using

git -add .

With git-add ., the files are initially put in Staging Area (see image above), also called Index. The Staging Area is a container that holds all files about to be committed. You can add single files with git-add [filename].

If you accidentally put files in your Staging Area you can remove them usegit reset (without the dot, to remove all staged files) or git reset [filename] to remove a specific file.

To put the files from the Index to the Local Repository use

git commit -m “[commit message]”

You can also combine both commands by using

git commit -a -m "[commit message]"

The commit message is a message that describes the reason for the commit, e.g. „bug xyz fixed“ or „user story #xyz“. It’s kind of like the name for the container, which holds the collection of files you committed. Each commit creates an entry into the commit history. You can list the commit history with: git log or git log --pretty=oneline for a more compact version.

[expand title=“Why don’t you commit each file separately, why is there a Staging Area?“]

In general, when you add a new feature to your software, you have to add and/or change more than one files. Just imagine you want to display the gender as a new field on your website. If this data is not available in the database, you might have to change some .java, .css, .js and other files. You put all these changes together in the Staging area and commit it. The commit history (git log) is clean and clear. Later you will see that you can set the working directory to a previous commit or see the changes you have made. If in contrast, you would commit each file separately, the context (display gender on your webpage) would be lost. In addition, the commit history would be confusing. This might sound simple now, but in a real project, you would work with other team members and the same data, which would make it even more confusing.

[/expand]

[expand title=“What is this HEAD?“]

As we haven’t discussed branches yet, the HEAD basically points to the latest commit in the MASTER (this is not 100% accurate but it gives you a picture).

[/expand]

To get a status of the files (untracked files that are not under version control, files that have changed but have not been added, files in the Index that haven’t been committed) use

git status

When you perform a git log you will notice that the commit names or references seem very cryptic, e.g.

commit 2a21b89d44a877b1d5892ef9f12cc89bd0a871f6
Author: chris <moser.christoph@gmx.de>
Date: Tue Mar 20 15:39:16 2018 +0100

2. Change to Master

commit dadbf09b4e94c72901f68e65d1440930418eee95
Author:chris <moser.christoph@gmx.de>
Date: Tue Mar 20 15:38:51 2018 +0100

1. Change to Master

Maybe later you want to switch back to an earlier commit or want to see the differences between the current state and an earlier state of your software in Git. With tagging, you can give important versions of your software a name, e.g. you want to release the current version of your Working Directory in production (-a = name (tag), -m = comment)

git tag -a v1.0 -m "First Release of your software"

You can list all tags using git tag or git log --decorate. For more detailed information use git show [tag-name].

The tag we created before is a so-called annotated tag. You can also use lightweight tags. These tags don’t contain much more information than a checksum (no author, comment, changes etc.).

git tag v1.0.1

If you want to switch to an earlier version of your code use

git checkout [tag-name]

If you use this command, Git will go into the so-called “detached HEAD” state (the HEAD is not pointing to the latest commit but to an earlier commit). There are ways to change earlier versions of your code, but I do not recommend it and hence will not go into detail here. I only recommend using it to look into an earlier version of your code or to deploy an older version of your software.

With git checkout master you can get back to the latest commit to work as usual.

If you want to see the differences between two versions use

git diff [tag-name 1] [tag-name 2]

or if you want to compare an earlier version with the current version use

git diff [tag-name] master

When you have lots of changes (which is the common case), you will use a graphical git-client, as diffs are displayed more structured.

Configuration

git config offers options to configure your git repository. Most settings can be applied global (parameter --global) or to your local (current) repository (parameter --local)

• Change the author in the commit-history in all repositories with: git config --global user.name [name]
• Change the author in the commit-history in your current local repository with: git config --local user.email [email]

Further Reading

GIT Tutorial – Basics

GIT Tutorial – Working with Branches – Part I

Git Branches – Working with Branches – Part II (Merge Conflicts)

Git Branches – Working with Branches – Part III (Merging versus Rebasing)

GIT Tutorial – Remote Repositories