Aus Claudio's Wiki
Wechseln zu: Navigation, Suche


Git is a Distributed Version Control System (DVCS).

Local Operations

Working directory
Files where you work
Staging Area
Staged diffs are ready to be committed
git repository
Committed files


System (/etc/gitconfig)
git config --system
Global (~/.gitconfig)
git config --global
Repository (%WORKINGDIRECTORY%/.git/config)
git config --local

Ignoring files

In workingdirectory:

vim .gitignore


git config --global core.autocrlf %value%

convert to CRLF on checkout and back to CR on commit:
     commit    checkout
CRLF  -->   CR   -->    CRLF
CR    -->   CR   -->    CRLF
convert CRLF to LF on commit:
     commit    checkout
CRLF  -->   CR   -->    CR
CR    -->   CR   -->    CR
don't change:
     commit    checkout
CRLF  -->   CRLF  -->   CRLF
CR    -->    CR   -->   CR

Working local

Clone existing Repository

git clone git://
That creates a directory named "grit", initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version
git clone git:// mygrit
Creates "mygrit" directory instead of "grit"

Check Status

git status

Statusmeldung: Your branch is ahead of 'origin/master' by 1 commit. -> Lokal ist 1 commit mehr vorhanden als origin/master.

Show log

git log
git log --stat

Mit Zusammenfssung der Änderungen

Formatting output

git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s"
git log --pretty=format:"%h %s" --graph

Limit output

git log --since=2.weeks
git log --2
git log --pretty="%h - %s" --author=gitster --since="2008-10-01" --before="2008-11-01" --no-merges

Stage files

A modified file under version control can be staged with the command

git add
or use
git gui

git add is also used to add new files to version control.

Commit files

git commit
git commit -m 'initial project version'

Remove files

git rm readme.txt

deletes the readme.txt file from working directory (file is really deleted) and from version control.

git rm --cached readme.txt

deletes the readme.txt file from version control, but not from working directory (file is still on filesystem).

Revert commits / Undo changes

git rebase -i

If the commit has not already been pushed, you can use git rebase -i.

git revert

If you have pushed, you can use the command

git revert [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>...

Most used options:

  Commits to revert. For a more complete list of ways to spell commit names, see gitrevisions(7). Sets of commits can also be given but no traversal is
  done by default, see git-rev-list(1) and its --no-walk option.
-e, --edit
  With this option, git revert will let you edit the commit message prior to committing the revert. This is the default if you run the command from a
  With this option, git revert will not start the commit message editor.
-n, --no-commit
  Usually the command automatically creates some commits with commit log messages stating which commits were reverted. This flag applies the changes
  necessary to revert the named commits to your working tree and the index, but does not make the commits. In addition, when this option is used, your
  index does not have to match the HEAD commit. The revert is done against the beginning state of your index.
  This is useful when reverting more than one commits' effect to your index in a row.


git revert -n df0e043088eacb5e8854973c0d575158269af7ff
  Reverts exactly the commit df0e043088eacb5e8854973c0d575158269af7ff

git revert HEAD~3
  Revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes.

git revert -n master~5..master~2
   Revert the changes done by commits from the fifth last commit in master (included) to the third last commit in master (included), but do not create any
   commit with the reverted changes. The revert only modifies the working tree and the index.

Working with Remotes

You must have cloned an existing Repository before working with remotes. See Clone existing Repository

Show remote repositories

git remote
git remote -v

Adding Remote Repositories

git remote add mic git@git-server:~mic/ishop-ap/mic-ishop-ap.git

Update repository

gets all changes from mic without merge:

git fetch mic

gets all changes from origin without merge:

git fetch origin

gets all changes from origin and merges to current branch (or master):

git pull origin

Pushing to Remotes

git push [remote-name] [branch-name]
git push origin master
Pushes your master branch to your origin server

Inspecting a Remote

git remote show origin

Merging / Rebase

git merge

Typische Nutzung:
git merge <commit>
git merge -m <msg> <commit>
Im master:
git merge topic
macht aus:

         A---B---C topic
   D---E---F---G master

einen neuen Eintrag (H):

         A---B---C topic
        /         \
   D---E---F---G---H master

in case of conflicts

topic  = theirs = remote version
master = ours   = local(current) version

git rebase

Im Gegensatz zu git merge 'kopiert' git rebase alle commits vom <source> auf dem <target>. Und zwar ab dem commit, wo sie sich getrennt haben.

         A---B---C branch (<source>)
   D---E---F---G master (<target>)

   D---E---F---G---A'--B'--C' branch

Rebase current branch on <target>:

git rebase <target>

Rebase <source>-branch on <target>:

git rebase <target> <source>

Das Rebasen funktioniert nur lokal. Also, wenn man ein Branch aus dem Remote-Repository rebasen will, muss dieser Branch lokal vorhanden sein. Ansonsten diesen Branch lokal erstellen vor dem Rebase. Falls der Source-Branch fehlt, wird trotzdem rebased, allerdings ist man dann in keinem Branch, sondern in einem 'Commit' (Hashtag).

in case of conflicts

<target> = ours = upstream


List tags

git tag
git tag -l '2.0.*'
lists only tags matching '2.0.*'-pattern

Create tags

Annotated (recommended)

Are stored as full objects in the Git database. They’re checksummed, contain the tagger name, e-mail, and date, have a tagging message

git tag -a v1.4 -m 'my version 1.4'

Lightweight (eg. for temporary use)

like a branch that doesn’t change — it’s just a pointer to a specific commit

git tag v1.4-1

Tipps and tricks

Use stash

Stash: Verstauen. 'Versorgt' die aktuellen Änderungen in einer Schublade, um es später wieder hervorzunehmen. Nützlich, wenn man Änderungen hat, die man noch nicht committen will, aber kurzzeitig zu einem anderen Projekt bzw. Branch wechseln will.

Lists the stashes:

git stash list

Save your local modifications to a new stash, and run git reset --hard to revert them. Saves with message: 'no idea what i'm doing here':

git stash save no idea what i'm doing here

Remove a single stashed state from the stash list and apply it on top of the current working tree state:

git stash pop stash@{0}

Like pop, but do not remove the state from the stash list:

git stash apply stash@{0}

Remove a single stashed state from the stash list:

git stash drop stash@{0}

show changes:

git stash show stash@{0}

Use bisect

Bisect: halbiern. Für die Fehlersuche, gibt man an, wo der Fehler noch nicht existierte und wo es existiert. Bisect checkt immer den commit in der Mitte aus un man kann prüfen, ob der Fehler noch existiert. Durch wiederholtes halbieren findet man heraus, bei welchem commit der Fehler entstanden ist.

Start bisect


git bisect start <bad> <good>


git bisect start project-new-db master
git bisect start 4b0bd09e46901f3151b4e55b67b3365dd9032e33 d289be1b199c9126b01e98cbc0c4119151150513


git bisect start
git bisect bad (current version is bad)
git bisect good 1.0.17 (1.0.17 was the last good version)


Deploy/Test the current version. If the bug still exist, use

git bisect bad


git bisect good

Re-Deploy/Test the current version until you reached the end of bisecting.


If you cannot test, skip the current version using

git bisect skip


When you’re finished, you should reset your HEAD to where you were before you started:

git bisect reset

Some command notes