Einleitung in die Benutzung von Git - Teil #1

2010-03-12 - kostaki 5 Kommentare »

Nachdem man Git installiert hat kann man sofort los legen. Ich hatte als erstes das Gittutorial vom Linuxkernel gelesen. Hier ist eine kurze deutsche Zusammenfassung/Übersetzung. Man sollte damit beginnen Git zu sagen wer man eigentlich ist. Dazu werden 2 Config Variablen gesetzt, mit denen man im Repository identifiziert wird.

$ git config --global user.name "kostaki"
$ git config --global user.email kostaki@gmx.net

Diese Daten werden im Homedir in der .gitconfig gespeichert. Braucht man mehr Informationen zu einem Bestimmten Git Befehl, kann man die Hilfe/Manpage zu einem Befehl wie folgt aufrufen.

$ git help log
$ man git-log

Begriffserklärung

Besonders für Anfänger ist es schwer sich etwas unter den Begriffen vorzustellen. Für Umsteiger haben manche Begriffe andere Bedeutungen oder funktionieren anders.

  • repository: Da Git ein DVCS ist, liegt das Repository immer im Projektverzeichnis (.git Ordner). Im Repository werden die Meta Informationen die zur Versionskontrolle nötig sind gespeichert.
  • commit: Unter einem Commit versteht man das speichern eines Änderungsstandes im Repository. Hat man also einen gewissen Punkt in der Entwicklung erreicht, dann kann man seine Änderungen ins Repository schreiben. Dazu wird der Commit Befehl benutzt. Beim commiten wird ein Kommentar der Anpassung erwartet, das die Änderung beschreibt.
  • clone: Ein Clone ist eine exakte Kopie des Projekts+Repository an einen andere Ort.
  • branch: Ein Branch ist ein mit einem Namen versehener Versionsstand in einem Repository. Man kann zwischen verschiedenen Branches springen und so an verschiedenen Versionen des gleichen Projekts arbeiten.
  • pull: Mit einem Pull kann man Änderungen von einem Clone in sein eigenes Repository kopieren und die Änderungen mit seinen eigenen Änderungen mischen.
  • merge: Von einem merge spricht man wenn man zwei oder mehrere Dateien mit unterschiedlichen Versionsständen zusammen fügt. Git unterstützt auto merges. Hierbei wird versucht die Zusammenführung der Dateien automatisch zu erledigen. So kann man auch gleichzeitig an einer Datei arbeiten. Sollte es Kollisionen der Arbeit geben, dann werden diese markiert und müssen im Anschluss von Hand bereinigt werden. Dies kann gefährlich sein, da auch Änderungen am Ende einer Datei, Bezug auf den Anfang haben können. Löscht 1 zum Beispiel eine Funktion und 2 schreibt eine Funktion die die gelöscht benutzt, dann merkt der merge dies natürlich nicht und funktioniert ohne Konfliktmeldung.

Neues Projekt erstellen oder Projekt importieren

Jetzt begibt man sich in die Root seines Projekts und initialisiert ein neues Git Projekt. (Vielleicht erstmal mit einem leeren Projekt starten zum üben).

$ mkdir gittest
$ cd gittest
$ git init
Initialized empty Git repository in gittest/.git/

Als nächstes fügt man alle Dateien im aktuellen Ordner und dessen Unterordner zum Git Projekt hinzu. Die Dateien/Ordner werden zuerst im Git „index“ gespeichert und noch nicht im eigentlichen Repository. Da es in unserem Fall noch keine Dateien gibt, legen wir erst ein paar an.

$ mkdir dirtest
$ touch tast tust tost
$ git add .

Will man nur einzelne Dateien oder Ordner hinzufügen, kann man anstelle des Punktes die Datei oder den Ordner angeben. Man kann auch mehrere Dateien/Ordner mit einem Aufruf angeben. Git kann keine leeren Verzeichnisse hinzufügen. Es muss immer eine Datei im Verzeichnis liegen, ansonsten wird das Verzeichnis ignoriert. Will man trotzdem ein leeres Verzeichnis hinzufügen, legt man eine Datei mit dem Namen "empty" darin ab.

$ git add tast tust tost dirtest

Wenn man nun Dateien zum Git "index" hinzugefügt hat und man diese im Repository speichern möchte, kann man dies mit git-commit machen. Man wird nach einer Beschreibung des commits gefragt und erhält eine Liste der Änderungen. Wie man sehen kann befindet sich das noch leere Verzeichnis nicht mit in der Auflistung.

$ git commit
# Please enter the commit message for your changes.
# (Comment lines starting with '#' will not be included)
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#       new file: tast
#       new file: tost
#       new file: tust
#

Um das Verzeichnis auch noch ins Repository aufzunehmen, legen wir die besagte empty Datei hinein.

$ touch dirtest/empty
$ git add dirtest
$ git commit

Dateien Bearbeiten

Hat man Dateien bearbeitet, fügt man sie zum Git index hinzu und commited sie.

$ nano tast
$ nano tost
$ nano tust
$ git add tast tost

Man muss hierbei nicht immer die genauen Dateien angeben die man bearbeitet hat. Es reicht auch ein git add . um alle Veränderungen zum index hinzuzufügen. Was genau jetzt commited würde (was also schon zum index hinzugefügt wurde), kann man sich mit „git diff --cached“ ansehen. Ruft man „git diff“ ohne „--cached“ auf, dann werden alle Änderungen angezeigt die noch nicht zum index hinzugefügt wurden. Um einen Überblick zu bekommen kann man auch git-status benutzen, das Dateien die im index sind und noch nicht im index sind anzeigt.

$ git diff --cached
$ git diff
$ git status

Ist man zufrieden mit seinen Änderungen, dann kann man sie mit git-commit commiten. Fügt man an git-commit noch ein -a an, dann fügt Git automatisch alle veränderten Dateien zum index hinzu (aber keine neuen Dateien!) und commited sie in einem Rutsch.

$ git commit
$ git commit -a

Bei der Vergabe der Beschreibung sollte man sich an eine kleine Konvention halten. In der ersten Zeile sollte kurz die Veränderung beschrieben werden, dann kommt eine Leerzeile gefolgt von einer etwas längeren Beschreibung. Das sollte man machen, da Programme die Commits per Mail verschicken, die erste Zeile als Subject und den Rest als Mailbody benutzen.

Projekt History betrachten

Der Hauptgrund für den Einsatz eines VCS ist natürlich die Versionskontrolle. Die unterschiedlichen Versionen des Projekts kann man sich mit git-log anzeigen lassen. Wer, was, wo und wann geändert hat wird so ersichtlich und nachvollziehbar.

$ git log

Will man die Kompletten Änderungen per Diff angezeigt bekommen, fügt man -p an.

$ git log -p

Branches erstellen und verwalten

In jedem Repository kann man mehrere Branches verwalten. Das sind Kopien des aktuellen Standes des Projekts, an denen man parallel arbeiten kann ohne das man sich einen neuen Clone erzeugen muss. Man kann zwischen den Branches hin und her switchen und so an mehreren Enden arbeiten ohne Rücksicht auf die Änderungen im anderen Branch nehmen zu müssen.

Einen neuen Branch mit dem Namen „malwastesten“ des aktuellen Projekts legt man wie folgt an:

$ git branch malwastesten

Wenn man jetzt git-branch ohne Parameter aufruft, bekommt man eine Liste der existierenden Branches zu sehen. Der aktuelle Branch ist mit einem Stern gekennzeichnet.

$ git branch
  malwastesten
* master

Mit dem Befehl git checkout kann man in ein anderes Branch wechseln.

$ git checkout malwastesten
Switched to branch "malwastesten"
$ git branch
* malwastesten
  master

Jetzt befinden wir uns im „malwastesten“ Branch und können Dateien editieren und diese commiten. Wenn wir dann in den master Branch wechseln sollten wir diese Änderung nicht sehen können.

$ nano tast
$ git commit -a
$ git checkout master

Im master Branch kann man nun weitere Änderungen vornehmen und diese commiten. Irgend wann will man natürlich beide Branches wieder zusammen fügen und das macht man mit git-merge.

$ git merge malwastesten

Wenn die Zusammenfügung ohne Probleme/Überschneidungen von statten gegangen ist, dann ist man nun fertig. Wenn es Änderungen gab die nicht automatisch gemerged werden konnten, dann kommt eine Konflikt Meldung und die Stellen die als problematisch erkannt wurden, werden in den Dateien markiert. Eine solche Meldung kann wie folgt aussehen:

Auto-merged tast
CONFLICT (content): Merge conflict in tast
Automatic merge failed; fix conflicts and then commit the result.

Sobald man das Problem gelöst hat, kann man die Änderungen ganz normal commiten. git-diff kann helfen die Probleme zu finden.

$ git diff
$ nano tast
$ git commit -a

Wenn man das „malwastesten“ Branch in den master eingebunden hat, kann man es löschen. Benutzt man das kleine „-d“, wird die History des Branches weiterhin im Master gespeichert. Wenn man nur mal was testen wollte und das dann verwerfen will, kann man das große „-D“ benutzen. git-branch zeigt abschließend nur noch den master an.

$ git branch -d malwastesten
$ git branch -D malwastesten
$ git branch
* master

Abschluss Teil 1

Im Teil 2 dieses Tutorials wird gezeigt wir man die Projekt History genauer erkunden kann und wir man Git zur Teamarbeit benutzen kann.

Related Links

  1. 5 Kommentare

  2. chris
    schrieb am 13.04.2014 um 17:29 Uhr

    Gute Anleitung – vielen Dank!

  1. Trackback(s)

  2. Nov 2, 2011:Projektversionierung in der Dropbox mit Git « systemfeld blog
  3. Nov 6, 2012:Git-Repos in der Dropbox | systemfeld
  4. Dez 28, 2012:Vorgehen: Git “ersten” Commit erstellen | Frag einen Webentwickler
  5. Nov 3, 2014:Vorgehen: Git “ersten” Commit erstellen | Website von Tim Bischoff, Webentwickler

Kommentar schreiben

*

*