Deutsche Startseite · English Homepage
STRAVID - Gemeinsam Software bauen.
Wer nicht weiß was git ist oder wieso er es ausprobieren und benutzen soll kann sein Wissen mit dem Beitrag git spart Arztkosten auffrischen!
Für Windows findet man die benötigten Dateien hier, die Mac User hier. In Linux funktioniert es am schnellsten mit diesem Ausdruck.
$ sudo apt-get install git-core
Wenn man will kann man noch die beiden zusätzlichen Pakete git-gui und git-doc installieren.
git verfügt zwar über eine Grafische Benutzeroberfläche, trotzdem arbeite ich aber nur mit der Konsole da es einfach schneller und praktischer ist sobald man sich die wenigen Befehle gemerkt hat.
Ist git installiert öffnen wir die Konsole, unter Windows bitte nicht die Windowseigene Konsole sondern die "Git Bash" die man im Startmenü findet, und geben git unsere Benutzerdaten, diese werden zu jedem Commit (was das ist wird weiter unten erklärt) mitgespeichert damit man immer sagen kann welche Teile von welcher Person stammen.
$ git config --global user.name "David Strauss" $ git config --global user.email "mail@stravid.com"
git arbeitet mit so genannten "Repositories", man könnte es als Ordner / Kontainer beschreiben in dem alle Projektdateien liegen. Normalerweise hat man pro Projekt ein Repository auf seinem Computer. Wir erstellen einen Ordner für unser Dummy-Projekt, darin erstellen wir dann eine einfache Textdatei. Und dann wirds spannend, mit git init sagen wir git es soll hier ein neues Repository erstellen.
$ mkdir dummy-projekt $ cd dummy-projekt $ touch readme.txt $ git init Initialized empty Git repository in d:/workspace/dummy-projekt/.git/
Was ist passiert? git hat in unserem "dummy-projekt" einen unsichtbaren Ordner namens .git erstellt. Diesen braucht git damit es unseren "dummy-projekt" Ordner als Repository erkennt, desweiteren speichert es dort drinnen alle relevanten Daten. Wir, der Benutzer haben in diesem Ordner nichts verloren!
git status ist der nächste Befehl den wir kennenlernen, er liefert uns eine aktuelle Übersicht über unser Repository: Welche Dateien wurden seid unserem letzten Commit bearbeitet und welche Dateien werden von git noch nicht getracked.
$ git status # On branch master # # Initial commit # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # readme.txt nothing added to commit but untracked files present (use "git add" to track)
Wir sehen das es eine Datei, readme.txt gibt die nicht getracked wird. Um das zu ändern verwenden wir den Befehl git add, dieser bewirkt folgendes: Der aktuelle Stand der Datei wird erfasst und die Datei ändert ihren git internen Status von "unstaged" zu "staged". Das bedeutet genau dieser Zustand der Datei wird beim nächsten Commit abgespeichert. Mit git status können wir das ganz einfach überprüfen.
$ git add readme.txt $ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: readme.txt #
Haben wir alle Dateien mit git add hinzugefügt die wir bei unserem Commit dabei haben wollen machen wir unseren ersten Commit mit dem Befehl git commit -m "Mein erster Commit". git speichert jetzt den Zustand der hinzugefügten Dateien in einem so genannten Commit.
$ git commit -m "Mein erster Commit" [master (root-commit) 2043aa1] Mein erster Commit 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 readme.txt
Jetzt öffnen wir unsere readme.txt mit einem Texteditor unserer Wahl und schreiben alle uns bekannten git Befehle hinein. Nach dem speichern wechseln wir wieder in unsere Konsole und geben git status ein, git hat erkannt das unsere Datei modifiziert wurde. Wir sind mit unserer Arbeit zufrieden und wollen wieder einen Commit machen, gerade als wir git add readme.txt eingegeben haben fällt uns ein das wir einen Befehl in der Datei vergessen haben, also fügen wir diesen noch schnell hinzu.
$ git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: readme.txt # no changes added to commit (use "git add" and/or "git commit -a") $ git add readme.txt
Wenn wir jetzt noch einmal git status eingeben sehen wir das readme.txt zweimal aufscheint. Wieso ist das so? Wir haben sie in der Zwischenzeit bearbeitet und git hat das gemerkt! Wenn wir jetzt einen Commit machen wird readme.txt in genau dem Zustand commited in dem sie beim hinzufügen war. Die Änderungen die wir am Ende noch schnell gemacht haben wären bei diesem Commit nicht dabei.
Dieses Verhalten ist in vielen Fällen praktisch, wir wollen aber in diesem Fall auch unsere letzten Änderungen beim commiten dabei haben deswegen müssen wir die Datei noch einmal stagen. An dieser Stelle eine Kurzvariante mit der man in nur einem Schritt alle modifizierten Dateien staged und gleichzeitig einen Commit macht. Dazu geben wir git commit -a -m "git Befehle hinzugefuegt" ein. Das Flag -a sagt git das alle Dateien die schon getracked werden und seit dem letzten Commit modifiziert wurden zu dem neuen Commit hinzugefügt werden sollen.
$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: readme.txt # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: readme.txt # $ git commit -a -m "git Befehle hinzugefuegt" [master warning: CRLF will be replaced by LF in readme.txt.73c0c45] git Befehle hinzugefuegt 1 files changed, 7 insertions(+), 0 deletions(-)
Das sind die minimalen Basics um mit git arbeiten zu können, sobald diese in Fleisch und Blut übergegangen sind kann man sich mit den restlichen Möglichkeiten von git auseinander setzen. Dazu gibt es bald einen weiteren git - Beitrag von mir!
Du hast Fragen, Ideen oder Anregungen? Ich lese gerne von dir und freue mich auf einen Austausch von Gedanken. Schreib mir an david@strauss.io und sag „Hallo“.