Skip to content

Users Guide Git Tutorial

scs edited this page Jul 14, 2012 · 2 revisions

Table of Contents

GIT

For development purposes, it has many advantages to use source code control software. GIT is the most flexible and powerful tool on Linux for that purpose, especially for decentralized OpenSource development because it can be used locally. GIT used to be hard to use, but with the graphical tools this has become much more intuitive. When working locally, everything you normally do can be done with one of the two GUIs (git-gui or gitk). All projects in the default Linux image are already checked into a local repository that can be used. This section aims to explain the most used commands and tools.

User configuration

Before starting GIT should be configured:

 $ git config --global user.name "Example Insurance Inc."
 $ git config --global user.email "you@example.com"

Alternatively, you can fill the file ~/.gitconfig with the following lines:

 [user]
     name = Example Insurance Inc.
     email = you@example.com

Create new project

If you would like to create a new repository, e.g. after copying app-template, you simply delete the .git/ folder that contains the repository and initialize a new one with the current contents of the folder:

 $ rm .git/ -rf
 $ git init
 $ git add .

Commiting code (git-gui)

There is a very nice graphical tool called git-gui that facilities commits. To invoke it type:

 $ git-gui &

On the right side of the window, the files that are not known to the repository appear white and the ones that are known but contain changes appear blue. When clicking on the file name, a diff to the version in the repository appears on the bottom. By clicking on the file icon, files are moved to the staging area, i.e. they will be added to the repository with the next commit. As long as no new files were added, the "Add existing" button is enough to stage all changes. The text field in the center allows specifying description for this commit. Afterwards, the files can be committed with the commit button. Note that not all files have to be committed in one go, you can first stage only part of the files to be committed with a specific commit message and then stage the next group to be committed with a different message.

Inspecting the history (gitk)

Another very helpful tool is gitk. It displays all commits in all branches that have been made on the project in a very appealing way:

 $ gitk --all &

It also allows you to create tags and branches etc.

Tagging

Create a new tag:

 $ git tag <Tag-Name>

Branching

Branching is really fast and flexible in GIT. Thus it is not uncommon for developers to work on 5-10 branches at the same time and opening up a new one for every feature or idea. As soon as the feature is ready, it can easily be merged back to the main branch. The default name for this main branch is `master` in GIT.

List local branches:

 $ git branch

Create new local branch and switch to it:

 $ git checkout -b <branch-name>

Switch to a branch:

 $ git checkout <branch-name>

Delete a local branch that was merged into another branch (safe delete):

 $ git branch -d <branch-name>

Delete a local branch that turned out to be a bad idea:

 $ git branch -D <branch-name>

Rebase a branch to the master level (current branch: <branch>)

 $ git rebase master

Merge a development branch back to master

 $ git checkout master
 $ git merge <feature-branch>

Check out an old revision

If the desired revision is tagged:

 $ git checkout <Tag-Name>

Otherwise you have to know the ID of the commit you want to check out. You can look this up by selecting the commit in gitk, which will then display its SHA1 ID. This is a 40 character hex-string that uniquely identifies every commit as well as its whole history.

 $ git checkout <SHA1>

Reverting all local, uncommited changes

This overwrites the sandbox with the HEAD commit of the repository. Note that there must be no files in the staging-directory of git-gui for this to work.

 $ git checkout .

Undo a commit

This `removes` the commit from the repository but leaves the sandbox as it was:

 $ git reset --soft HEAD^

If you want to reset the working directory as well, you can use:

 $ git reset --hard HEAD^

The number of ^'s behind the HEAD determines how many commits are undone.

Clone this wiki locally