Einleitung in die Benutzung von Git - Teil #2

2010-03-12 - kostaki Keine Kommentare »

Im ersten Teil dieses Tutorials wurde der Einstieg in Git beschrieben. In diesem Teil wird näher auf die Verwendung der Git History und auf das verwenden von Git in der Teamarbeit eingegangen.

Die Git Projekt History erkunden

Das Git Repository besteht aus einer Vielzahl von Commits, die man sich mit git log auflisten lassen kann. Will man nun aber genauere Details zu einem Commit haben kann man sich diese mit git-show anzeigen lassen. Jeder Commit bekommt dies bezüglich einen Namen. Das ist die erste Zeile eines jeden Commits der im git-log angezeigt wird. Name ist wohl übertrieben, aber mit Hilfe dieses Hashes kann jeder Commit nachverfolgt werden. Mit Hilfe von git-tag kann man einzelnen Commits auch verständliche Namen geben.

$ git log
commit 20a0ac493a366285bc0daed5f535bbbb4d46440d
Merge: bba5453... 0e9d235...
Author: kostaki <kostaki@gmx.net>
Date:   Tue Jan 12 17:08:40 2010 +0100

Jetzt nimmt man sich den Hash und übergibt ihn an git-show um sich die genauen Änderungen anzusehen. Man muss nicht den gesamten Hash kopieren. Meistens reicht der Anfang um den jeweiligen Eintrag zu identifizieren.

$ git show 20a0ac493a366285bc0daed5f535bbbb4d46440d
commit 20a0ac493a366285bc0daed5f535bbbb4d46440d
Merge: bba5453... 0e9d235...
Author: kostaki <kostaki@gmx.net>
Date:   Tue Jan 12 17:08:40 2010 +0100

    Merge branch 'malwastesten'

    Conflicts:

        tast

diff --cc tast
index 9daeafb,07dda2b..077e4cf
--- a/tast
+++ b/tast
@@@ -1,1 -1,1 +1,1 @@@
- test
 -babuba
++tatuta

Weitere Wege um sich Commit Details anzeigen zu lassen sind diese.

$ git show 20a0ac493 # wie beschrieben der Anfang reicht auch meistens
$ git show HEAD # der letzte Commit
$ git show malwastesten # der letzte Commit des Branches

Der letzte Befehl liefert einen Fehler, wenn man die History den Branch mit „-D“ komplett gelöscht hat. Ansonsten sieht man den letzten Commit dieses Branches. Vorletzte und Vorvorletzte Commits kann man sich so anzeigen lassen:

$ git show HEAD^  # Vorletzte
$ git show HEAD^^ # Vorvorletzte
$ git show HEAD~4 # ...

Hat man merge Commits, dann können diese natürlich mehrere „Eltern“ haben.

$ git show HEAD^1 # das gleiche wie HEAD^
$ git show HEAD^2 # das zweite merge „Elternteil“

Wie schon erwähnt kann man einzelnen Commits auch verständlichere Namen geben. Diesen Namen kann man jedem Git Programm geben das einen Commitnamen erwartet. Der Name muss natürlich eindeutig sein!

$ git tag version2.5 20a0ac493

Nun kann ich den Namen „version2.5“ verwenden.

$ git show version2.5
$ git diff version2.5 HEAD^ # um die beiden Version zu vergleichen
$ git branch testenochmal version2.5 # um einen Branch von dieser Version zu erzeugen

Mit Hilfe von git-grep kann man in seinem Git Projekt nach Texten suchen. Man kann den Commitnamen angeben, dann wird nur in diesem gesucht oder man lässt ihn weg, dann wird in allen Dateien des aktuellen Verzeichnisses gesucht (und Unterverzeichnisse).

$ git grep 'hallo'
tust:hallo
$ git grep 'hallo' version2.5
version2.5:tust:hallo

Vielen Git Programmen kann man auch mehrere Commits oder Ranges zwischen Commits angeben.

$ git log version2.5..version2.6 # Commits zwischen 2.5 und 2.6
$ git log version2.5.. # Commits seit v2.5
$ git log --since="2 weeks" # Commits der letzten 2 Wochen
$ git log v2.5.. tust # Commits seit 2.5 die die Datei tust betreffen

Wer einen X Server am laufen hat, kann auch gitk benutzen um eine visuell aufbereitete Version zu erhalten, die besser lesbar sein soll. (ich habe keinen)

Die meisten Git Programme die einen Dateinamen erwarten, kann man auch mit einem Commitnamen verknüpfen.

$ git diff version2.5:tust HEAD^:tust
$ git show version2.5:tust

Git zur Teamarbeit benutzen

Da ich die Standardnamen recht langweilig finde, heißt bei mir der Ersteller des Projekts Ralf und Lisa möchte daran mit arbeiten. Als erstes muss sich Lisa eine Kopie / einen Clone des Repositorys von Ralf besorgen. Das geht mit git-clone.

lisa$ git clone /home/ralf/projekt meineversion
Initialized empty Git repository in /home/lisa/meineversion/.git/

Lisa braucht natürlich Leserechte für alle Dateien in Ralfs Projekt Verzeichnis, damit es funktioniert. Lisa hat nun eine komplette Kopie (samt History) des Projekts in ihrem Homedirectory im Verzeichnis „meineversion“ und kann an diesem arbeiten. Nicht wundern sollte man sich über die Ausgabe das ein leeres Repository erstellt wurde. Es handelt sich um eine komplette Kopie des Projekt Repositorys von Ralf mit allen schon enthaltenden Änderungen. Wer es überprüfen will, kann dies mit einem git log machen.

Lisa macht nun ein paar Änderungen an den Dateien und commitet diese. Wenn Lisa fertig ist, sagt sie Ralf Bescheid.

lisa$ nano tast
lisa$ nano tust
lisa$ git commit -a
Created commit 4843e06: lala1
 2 files changed, 3 insertions(+), 0 deletions(-)

Ralf kann die Änderungen nun pullen. Auch hierfür müssen wieder die richtigen Zugriffsrechte gesetzt sein.

ralf$ cd /home/ralf/projekt
ralf$ git pull /home/lisa/meineversion master
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2)remote: , done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From /home/lisa/meineversion
 * branch            master     -> FETCH_HEAD
Updating f71337c..4843e06
Fast forward
 tast |    2 ++
 tust |    1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

Ralf hat jetzt die Änderungen von Lisas master Branch in sein aktives Branch kopiert. Wenn es Konflikte gegeben hätte, dann müsste Ralf diese nun beseitigen. Bevor man einen Branch pullt, sollte man aktive Änderungen commiten, damit alles Problemlos funktioniert.
Möchte Lisa ihre Version des Repositorys auf den aktuellen Stand bringen, dann kann sie dies mit einem simplen git pull machen. Der Pfad ist nicht nötig, da Git diesen in der Repository Config speichert.

lisa$ git pull
From /home/ralf/projekt/
   f71337c..4843e06  master     -> origin/master
Already up-to-date.
lisa$ git config --get remote.origin.url
/home/ralf/projekt/.git

Die Pfadangaben müssen auch nicht lokal sein. Man kann clone auch per SSH oder http nutzen.

Abschluss

Jetzt hat man einen Überblick über die wichtigsten Git Befehle und man könnte anfangen damit zu arbeiten.

Related Links

Kommentar schreiben

*

*