• alle Daten eines Repositories sind auf jedem Teilnehmer vollständig vorhand
• nahezu alle Operationen laufen lokal ab (es bedarf grundsätzlich keines Servers)
• Dateien die sich zwischen den Commits nicht ändern, sind nur Links die auf die zuletzt geänderte Version der Datei verweisen

• Unterscheidung in Meta-Objekte und Blobs
  • Meta-Objekte sind die Verwaltungsinformationen und Blobs die eigentlichen verwalteten Dateien

• Ein Commit erzeugt
  • ein Commit-Object
    • enthält die Metadaten
      • Commiter
      • Autor
      • Message
      • Prüfsumme
      • usw.
    • enthält Verweise auf die vorhergehenden Commits
  • ein Tree-Objekt
    • bildet die Verzeichnisstruktur
    • verweist auf die Dateien
      • wurde eine Datei nicht im aktuellen Commit geändert verweist der Pointer auf die Datei im letzten Commit wo sie geändert wurde
  • Blob-Objekte
    • die eigentlichen Dateien die geändert wurden
    • es wird immer die komplette Datei gespeichert, kein Delta

• Entwicklungszweige die parallel existieren für das gleiche Repository
  • häufig gibt es einen Master-Branch und davon abzweigende Sub-Branches (zum Beispiel für Patches oder wenn etwas ausprobiert wird)
• per git checkout kann zwischen Branches gewechselt werden
• Branches sind intern Pointer auf ein bestimmtes Commit

Wird ein neuer Branch erstellt:

• wird ein neuer Zeiger mit dem Namen des Branches erstellt
• der Zeiger zeigt initial auf das letzte gemeinsame Commit mit dem Branch aus dem er entstanden ist

• Siehe Objekte-Sektion
• zusätzlich verweist der Head-Pointer auf den neuen Commit (wird entsprechend verschoben)
  • der Head-Pointer existiert nur einmal pro git-Projekt und verweist immer auf das aktuelle (gewählte, muss nicht das letzte sein) commit im aktuellen Branch
    • der Inhalt des Working Directory und der Commit auf den der Head-Pointer verweist stimmen immer überein

• Remote-Repositories sind Repositories in die hochgeladen werden kann
  • sie sind eine „Kopie“ vom lokalen Branch
  • sie müssen nicht alle Branches enthalten die auch lokal vorhanden sind
• Remote-References sind Pointer auf bestimmte Objekte im Remote-Repository
  • Branches, Tags usw.
  • sie können aufgelistet werden mit remote show

• Remote-Tracking-Branches sind Pointer die auf den Commit Remote zeigen an dem das letzte Mal mit dem jeweiligen Remote-Branch kommuniziert wurde (fetch, pull, push)
  • Remote-Tracking-Branches haben die Form:

<Remote>/<Branch>

• Remote steht dabei für den Namen des Remote-Repository (git remote show)
• Branch ist der Name des Branches
• man kann für ein Repository auch mehrere Remote-Tracking-Branches haben
• macht man ein pull gegen eines und dies hat einen älteren Stand als man selbst (weil das zweite Remote-Repository einen neueren Stand hat) wird nur der Remote-Tracking-Pointer für das mit dem älteren Stand auf den neuesten Commit den es hat gesetzt - ansonsten passiert nichts (es wird nicht automatisch upgedated, man bekommt auch keine Daten → da man eh neuere hat)
• push ist einfach → git push <Remote-Name>
• neues Repository pushen (welches noch nicht Remote vorhanden ist): git push <Remote> <Repository-Name>
• soll das Repository remote unter einem anderen Namen erscheinen: git push <Remote> <Lokaler Name>:<Remote-Name>

• Lädt eine Kopie eines Remote-Repository

Syntax:

git clone <URL> [directory]

• URL: URL des Remote-Repository
  • https://Pfad
  • oder user@server:/Pfad → für ssh
• directory: Optional das Verzeichnis in welchem das heruntergeladene Repository abgelegt werden soll
  • ansonsten wird das letzte Verzeichnis im Quellpfad als Name genommen

• Fügt eine Datei zum Tracking hinzu
• oder zum Staging wenn sie schon im Tracking ist

Dateien im Repository-Verzeichnis werden nicht automatisch auf Änderungen hin überwacht.
Erst wenn sie per git add <Dateiname> zum tracking hinzugefügt wurden überwacht sie git.
Überwachen heißt das es bei einem commit weiß das die Datei geändert wurde und darauf hinweist, wenn sie nicht zu Staging hinzugefügt wurde (und damit nicht Teil des commits wird).
Um eine Datei die bereits getrackt wird zum staging hinzuzufügen benutzt man ebenfalls git add <Dateiname>.

Syntax:

git add <Dateiname>

Der Befehl unterstützt auch Wildcards.

• Zeigt den Zustand von staging an (als Zusammenfassung der Änderungen)
• es wird gelistet welche Dateien für ein commit vorgemerkt wurden
• welche Dateien verändert wurden und nicht gestaged wurden (aber getrackt werden)
• welche Dateien nicht getrackt werden

• Zeigt die konkreten Änderungen (Vergleicht den Quelltext) zwischen Working-Directory und staging
• oder staging und Repository an

Ohne Parameter → Unterschied zwischen Working-Directory und staging.
Mit Parameter

--cache

→ Unterschied zwischen staging und Repository.

• Checked Staging ein
• Die Änderungen werden fest ins Repository geschrieben und man kann später zu diesem Punkt zurückkehren

Syntax:

git commit

Optionen:

--amend

Entferne Dateien komplett oder nur aus dem Tracking und damit aus dem Repository.

Syntax:

git rm <Dateiname/Verzeichnisname>

Ohne Optionen wird die Datei aus dem Dateisystem und aus dem Tracking und damit aus Staging und damit aus zukünftigen commits entfernt.

Verschiebt/benennt eine Datei im Working Directory um und git bekommt es mit.

Grundsätzlich könnte man auch das normale mv/verschieben nehmen und die Datei per git rm unter altem Namen löschen und mit git add unter neuem Namen wieder hinzufügen und git wüsste in der Regel immer noch das es die gleiche Datei ist.

Zeigt den Veränderungsverlauf der eingecheckten/commitetten Daten.

Per Default wird nur eine Zusammenfassung angezeigt und die Prüfsumme des Commits an.

--graph

Filtern:

--since/--after

--until/--before

--since

--author

--grep

--all-match

--grep

--author

--grep

--all-match

Nimmt eine Datei die gestaged wurde aus dem Staging-Area.

Syntax:

git reset HEAD <Dateiname>

Es kann sein, dass man eine Datei in Staging geadded hat die (noch) nicht commited werden soll z.B.

Managed Remote-Repositories.

Ohne Option listet es die Remote-Repository.

Nach git clone gibt es ein Remote-Repository namens „origin“, das ist das von dem gecloned wurde.

Syntax:

git remote add <Kurzname> <URL> 

• Kurzname ist der Name unter dem das Repository angesprochen werden kann
• URL ist die URL unter der das Repository zu finden ist

Details über das Remote-Repository (u.a. welche Branches existieren usw.).

Syntax:

git show <Remote>

• Remote ist der Kurzname des Remote-Repositories

Umbenennen des Kurznamens für ein Remote-Repository.

Syntax:

git remote rename <Alter-Name> <Neuer-Name> 

Entfernen eines Remote-Repository

Syntax:

git remote rm <Remote>

• Zieht die Änderungen aus einem Remote-Repository
• es wird allerdings nicht gemerged und lokal modifizierte Dateien werden nicht angefasst
  • es muss dann ggf. manuell gemerget werden

Syntax:

git fetch <Remote>

• Remote ist das Kürzel des Remote-Repositories

• Zieht sich die Änderungen aus einem Remote-Repository und merged sie gegen das Working-Directory

Syntax:

git pull <Remote>

• Remote ist das Kürzel des Repositories von dem heruntergeladen wird

• Die Option „–rebase“ holt alle Änderungen von Remote, macht aber statt merge, ein rebase
  • das heißt die Änderungen von Remote werden nicht nach den lokalen Commits hinzugefügt, sondern die Remote-Änderungen werden erst eingespielt und dann alle lokalen Änderungen oben drauf angewendet

• Lädt die Änderungen aus dem lokalen Repository in ein oder mehrere Remote-Repository
• Die Änderungen dürfen dabei nicht im Konflikt zu Änderungen stehen die inzwischen im Remote-Repository gemacht wurden
  • das schlägt fehl

Syntax:

 git push <Remote> <branch> 

• Remote ist das Repository in das gepusht werden soll
• branch → der Branch in den hochgeladen werden soll

• Tags dienen der Markierung eines bestimmten Commits
  • z.B. um zu markieren das ein Commit einer bestimmten Version entspricht
• Tags werden nicht automatisch mit push auf Remote-Branches transferiert
• Es gibt Annotated und Leightweight Tags
  • Annoted sind eigenständige Objekte in der git-Datenbank
  • Leigthweight sind Branch-Ähnliche Verweise

• Man kann für den letzten commit/Head den Tag anlegen

Annotation Tag:

Syntax:

git tag -a <Tag> -m <Commentar>

• Tag → Der Tagname
• Commentar → „-m <Commentar> ist optional, wird das nicht angegeben wird der Editor gestartet für den Kommentar

Leightweight Tag:

Syntax:

git tag <Tag>

• Tags können auch nachträglich einem commit zugeordnet werden

Syntax:

git tag -a <Tag> <Commit-Prüfsumme>

• Tag → der Name des Tags
• Commit-Prüfsumme → die SHA1-Prüfsumme (siehe git log) des commits

• per Default werden Tags nicht mit Remot-Repository geteilt

Ein einzelnes Tag hochladen: Syntax:

git push <Remote> <Tagname>

• Remoe → Remote-Repository zu dem gepushed werden soll
• Tagname → Der Tagname der gepushed werden soll

Alle Tags pushen:

Syntax:

git push <Remote> --tags

Listet die Tags auf.

Syntax:

git tag -l

Man kann auch Wildcards benutzen, um nur Tags anzuzeigen die mit einer bestimmten Zeichenfolge beginnen:

Beispiel:

git tag -l 19.*

Syntax:

git tag -d <Tag>

• Funktioniert wie auschecken eines Commits - nur mit der Tag-Bezeichnung anstelle der Prüfsumme

Syntax:

git checkout <Tag>

• Anzeigen, Löschen und Anlegen, Verwalten von Branches

Branches listen:

git branch

Der Branch mit dem führenden * ist der aktuelle (im Working-Directory befindliche) Branch

Branche erstellen:

git branch <Name des Neuen Branches>

Obiges erstellt einen neuen Branch basierend auf dem aktuellen Head (dem Stand der durch das letzte Commit im aktuellen Branch entstandenn ist) unter dem angegebenen Namen.
Achtung: Es wird nicht in den neuen Branch gewechselt - der Inhalt des Working Directory ist immer noch der alte Branch.
Technisch gesehen wird erstmal nur ein Zeiger mit dem Namen des neuen Branches erstellt, der auf die Position des letzten Commits des Branches verweist aus dem er hervorgegangen ist.

Branch umbenennen:

git branch -m <Alter Name> <Neuer Name>

-m steht für move.

Branch löschen:

git branch -d <Branchname>

Letzten Commit für alle Branches anzeigen:

git branch -v

Alle gemergten Branches anzeigen (alle die die auf den gleichen Commit zeigen - dazu zählen auch die die noch gar nicht geändert wurden):

git branch --merged 

Alle nicht gemergten Branches anzeigen (alle die nicht auf den gleichen Commit wie der aktuelle Branch) zeigen:

git branch --no-merged

• Definiert welcher Stand im Working-Directory angezeigt wird
  • man Kann Branches oder bestimmte commits „auschecken“ - der Standd wird dann im Working-Directory angezeigt

Branch auschecken:

git checkout <Branchname>

Mit dem auschecken eines Branches wird dieser der aktive Branch - anschließende Commits werden in diesen gemacht

Commit auschecken:

git checkout <Commit-Checksumme>

Achtung: Oben stehende Methode checked in den aktuell aktiven Branch aus → Commits werden diesem hinzugefügt

Commit auschecken und neuen Branch mit diesem Beginnen:

git checkout -b <Commit-Checksum> <Branch-Name>

In diesem Fall wird auch gleich in den entsprechenden Branch gewechselt

• Überführt die Änderungen eines Branches in die eines anderen - häufig einen „Unterbranch“ in den master-Branch
• Dabei wird in den Branch gemerged in dem man sich aktuell befindet
  • befindet man sich in master und merged patch58, dann werden die Änderungen aus Branch „patch58“ in master übernommen, aber nicht umgekehrt

Syntax:

git merge <Branch>

Es kann passieren das es einen Merge-Konflikt gibt, weil einige Dateien in beiden Branches geändert wurden vor der Zusammenführung.
In diesem Fall schlägt das mergen fehl, die entsprechenden Dateien enthalten an den Stellen wo es den Konflikt gibt entsprechende Markierungen und den Inhalt beider Dateien.
Nach dem sich für eine der beiden Versionen entschieden wurde oder eine ganz neue Lösung gefunden wurde, müssen die Markierungen und der überflüssige Code gelöscht werden, danach wird normal commited.

• Damit kann bei merge-Konflikten ein Werkzeug (welches nicht Teil von git ist, sondern konfiguriert werden muss) aufgerufen werden um merge-Konflikte zu lösen

Syntax:

git mergetool

• Ändert die Git-History

• Wenn sich remote etwas geändert hat, kann der Remote-Stand untergehoben werden (aktueller, noch nicht gepushter Commit wird gestashed, die Änderung aus einem anderen Branch (aktueller Stand) eingespielt und die gestashten Änderungen als letzter Commit oben drauf gesetzt)
• noch nicht gepushte Commits können nachträglich bearbeitet werden
  • zusammengeführt werden (squash)
  • Änderungen vorgenommen werden

• Zusammenführen mehrerer (ungepushter) Commits zu einem

git rebase -i <Basis>

Basis:

• meint alle Commits nach dem als Basis angegeben Commit stehen als Edit zur Verfügung
• HEAD~[Anzahl Commits zurück] → nimm den Commit x Commit zurück als Basis
• <Branch> benutze den Commit an dem sich der aktuelle Branch vom angegebenen Branch getrennt hat (aka. den Base-Commit des aktuellen Branches)
• <SHA1-Sum of Commit> benutze den Commit mit der angegeben SHA1-Summe (siehe git log) als Basis

• Im sich öffnenden Editor alle Edits die mit dem letzten (oberster Eintrag) zusammengeführt werden sollen mit dem Keyword squash versehen (anstatt von pick)
• Editor mit schreiben beenden

• Definiert Dateien die ignoriert werden
• die Dateien werden auch mit git add .* nicht zu Staging hinzugefügt
• sie werden in git status nicht als „nicht getrackte“ Dateien geführt

• Datei befindet sich im Working-Directory
• Wildcards werden unterstützt (Glob-Pattern)
• die Zeichenketten werden auf die gesamte Verzeichnisstruktur im Arbeitsverzeichnis angewendet

Beispiel:

*test.py
*[ao].py

Ignoriert alle Dateien die auf test.py enden oder auf a.py oder o.py enden.

Folgende Zeichen haben neben den üblichen Wildcards eine spezielle Bedeutung:

/

!

Unterstützte Glob-Pattern: