Listing 4
$ git a add am annotate apply archive $ git --help Verwendung: git ... <command> [<args>]
Projekt fortführen
Im weiteren Verlauf ändert sich die Datei projekt.txt. Diese Versionen übernehmen Sie mit den Kommandos add und commit. Das Kommando git status zeigt den Status der Dateien im Arbeitsverzeichnis an. In Listing 5 ist zu sehen, wie sich der Status der Datei projekt.txt nach dem Kommando git add projekt.txt von Änderungen, die nicht zum Commit vorgemerkt sind zu zum Commit vorgemerkte Änderungen hin ändert.
Listing 5
$ echo "neue Zeile" >> projekt.txt $ git status Auf Branch master Änderungen, die nicht zum Commit vorgemerkt sind: (benutzen Sie "git add <Datei>...", um die Änderungen zum Commit vorzumerken) (benutzen Sie "git checkout -- <Datei>...", um die Änderungen im Arbeitsverzeichnis zu verwerfen) geändert: projekt.txt keine Änderungen zum Commit vorgemerkt (benutzen Sie "git add" und/oder "git commit -a") $ git add projekt.txt $ git status Auf Branch master zum Commit vorgemerkte Änderungen: (benutzen Sie "git reset HEAD <Datei>..." zum Entfernen aus der Staging-Area) geändert: projekt.txt $ git commit -m "neue Zeile eingefügt" [master 9d71c8d] neue Zeile eingefügt 1 file changed, 1 insertion(+)
Der Befehl git add unterstützt dabei die Angabe von Mustern für Dateien und Verzeichnisse sowie weitere Optionen. Über git add -u bringen Sie alle im Index eingetragenen, modifizierten Dateien in die Staging Area. Die Tabelle “Für den Einstieg” zeigt die bisher verwendeten Kommandos.
|
Kommando |
Funktion |
|---|---|
|
|
Leeres Repository anlegen oder initialisieren. |
|
|
Dateien zur Staging Area hinzufügen (Basis für ein Commit). |
|
|
Versionen aus der Staging Area ins Projektarchiv übernehmen. |
|
|
Status der Dateien im Arbeitsverzeichnis abfragen. |
Und jetzt?
Git verwaltet jetzt das Projekt, aber was bringt es nun effektiv? Zunächst mal die History, die Sie mit git log einsehen. Der Auszug aus Listing 6 zeigt ein Projekt mit zwei Commits, was zwei Versionen entspricht.
Listing 6
$ git log commit 9d71c8dd00db5bfb7e21ac8884356d0af284b1b8 (HEAD -> master) Author: Otto Muster <[email protected]> Date: Fri May 11 15:22:13 2018 +0200 neue Zeile eingefügt commit e29f38d1bc7625090 Author: Otto Muster <[email protected]> Date: Thu May 10 09:35:53 2018 +0200 Erster Commit
Jeder Commit ist mit einem 40-stelligen SHA1-Hash, im Folgenden als nur Hash genannt, gekennzeichnet. Dieser dient zum eindeutigen Identifizieren und als Checksumme. Bei einigen Kommandos ist es möglich, den Hash als Parameter anzugeben, wobei die Angabe der ersten 8 bis 10 Stellen oft ausreicht.
So gibt das Kommando git log 77558e4ac nur die Log-Nachricht bis zum angegebenen Commit aus. Im Terminal funktioniert das Kopieren und Einfügen des Hash mit der Maus, indem Sie mit der linken Maustaste auf den Hash doppelt klicken und ihn über einen einfachen Klick mit der mittleren Maustaste wieder einfügen.
Die Tabelle “Erweiterte Kommandos” enthält einige Kommandos inklusive möglicher Optionen für den Umgang mit den versionierten Daten. Zu jedem gibt es eine Vielzahl weiterer Optionen. Ein Blick in die spezifische Seite des Handbuchs zeigt diese an.
|
Kommando |
Funktion |
|---|---|
|
|
Versionen inklusive Hash zum Identifizieren anzeigen. |
|
|
Unterschiede zwischen Arbeitsverzeichnis und Staging Area anzeigen. |
|
|
Unterschiede zwischen Staging Area und letztem Commit anzeigen. |
|
|
Unterschiede zwischen Arbeitsverzeichnis und Commit |
|
|
Unterschiede zwischen den angegebenen Commits anzeigen. |
|
|
Dateien aus der Staging Area herausnehmen. |
|
|
Dateien im Arbeitsverzeichnis auf eingecheckten Stand zurücksetzen. |
|
|
|
|
|
Alle Dateien der angegebenen Version auschecken. Achtung: bereits eingecheckte Versionen dürfen Sie nicht mehr modifizieren. |
Das Kommando lautet git difftool und verhält sich wie git diff, startet jedoch ein externes Programm (Abbildung 6). Git sucht dabei nach typischen Programmen dieser Art. Über das Kommando git config --global diff.tool Programm> legen Sie bei Bedarf eins fest.
Abbildung 6: Mit dem Befehl git difftool rufen Sie ein externes Programm zum Betrachten der Unterschiede zwischen Dateien auf, im Beispiel Meld.
Remote-Repository
Bisher gibt es nur das lokale, im Projektverzeichnis befindliche Repository. Ein typisches Projekt stammt jedoch in der Regel aus einem sogenannten Remote Repository. Dieses klonen Sie lokal, was letztendlich einer exakten Kopie der entfernten Daten nebst den Metadaten für Git entspricht.
Zum Erstellen eines entfernten Repositorys erzeugen Sie aus den lokalen Daten ein Bare Repository. Im Vergleich zu dem lokalen Repo enthält dieses kein Arbeitsverzeichnis.
Sie haben dann die Möglichkeit, das Bare Repository in ein entsprechendes Verzeichnis, in Listing 7 ~/gitrepo/, zu verschieben. Anschließend dürfen Sie das bestehende Projektverzeichnis umbenennen oder löschen. Das neu erstellte Remote Repository klonen Sie einfach, wobei Git das Unterverzeichnis anlegt.
Listing 7
$ cd ~/mprojekt/../ $ git clone --bare mprojekt mprojekt.git Klone in Bare-Repository 'mprojekt.git' ... $ mv mprojekt.git gitrepo $ cd $ mkdir gitrepo $ mv mprojekt/ mprojekt_old $ cd $ git clone /home/otto/gitrepo/mprojekt.git Klone nach 'mprojekt' ... $ cd mprojekt $ git remote show origin * Remote-Repository origin URL zum Abholen: /home/otto/gitrepo/mprojekt.git URL zum Versenden: /home/otto/gitrepo/mprojekt.git Hauptbranch: master Remote-Branch: master gefolgt Lokaler Branch konfiguriert für 'git pull': master führt mit Remote-Branch master zusammen Lokale Referenz konfiguriert für 'git push': master versendet nach master (aktuell)
