Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- git [2018/10/30 18:02]
root [add]
+++ git [2022/02/07 21:50] (aktuell)
root [pull]
@@ Zeile 4: / Zeile 4: @@
   * 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
+====== Konzept ======
+===== Objekte =====
+  * 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
+===== Branches ======
+  * 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
+===== Commit =====
+  * 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 =====
+  * 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:
+<code>
+<Remote>/<Branch>
+</code>
+      * 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>
@@ Zeile 163: / Zeile 240: @@
   * Kurzname ist der Name unter dem das Repository angesprochen werden kann
   * URL ist die URL unter der das Repository zu finden ist
+==== show ====
+Details über das Remote-Repository (u.a. welche Branches existieren usw.).
+Syntax: <code>git show <Remote></code>
+  * Remote ist der Kurzname des Remote-Repositories
+==== rename ====
+Umbenennen des Kurznamens für ein Remote-Repository.
+Syntax: <code>git remote rename <Alter-Name> <Neuer-Name> </code>
+==== rm ====
+Entfernen eines Remote-Repository
+Syntax: <code>git remote rm <Remote></code>
+===== fetch =====
+  * 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: <code>git fetch <Remote></code>
+  * Remote ist das Kürzel des Remote-Repositories
+===== pull =====
+  * Zieht sich die Änderungen aus einem Remote-Repository und merged sie gegen das Working-Directory
+Syntax: <code>git pull <Remote></code>
+  * 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
+===== push =====
+  * 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: <code> git push <Remote> <branch> </code>
+  * Remote ist das Repository in das gepusht werden soll
+  * branch -> der Branch in den hochgeladen werden soll
+===== tag =====
+  * 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
+==== anlegen für letzten commit/Head ====
+  * Man kann für den letzten commit/Head den Tag anlegen
+Annotation Tag:
+Syntax: <code>git tag -a <Tag> -m <Commentar></code>
+  * Tag -> Der Tagname
+  * Commentar -> "-m <Commentar> ist optional, wird das nicht angegeben wird der Editor gestartet für den Kommentar
+Leightweight Tag:
+Syntax: <code>git tag <Tag></code>
+==== nachträglich anlegen ====
+  * Tags können auch nachträglich einem commit zugeordnet werden
+Syntax: <code>git tag -a <Tag> <Commit-Prüfsumme></code>
+  * Tag -> der Name des Tags
+  * Commit-Prüfsumme -> die SHA1-Prüfsumme (siehe git log) des commits
+==== hochladen ====
+  * per Default werden Tags nicht mit Remot-Repository geteilt
+Ein einzelnes Tag hochladen:
+Syntax: <code>git push <Remote> <Tagname></code>
+  * Remoe -> Remote-Repository zu dem gepushed werden soll
+  * Tagname -> Der Tagname der gepushed werden soll
+Alle Tags pushen:
+Syntax: <code>git push <Remote> --tags</code>
+==== auflisten ====
+Listet die Tags auf.
+Syntax: <code>git tag -l</code>
+Man kann auch Wildcards benutzen, um nur Tags anzuzeigen die mit einer bestimmten Zeichenfolge beginnen:
+Beispiel: <code>git tag -l 19.*</code>
+==== entfernen ====
+Syntax: <code>git tag -d <Tag></code>
+==== auschecken ====
+  * Funktioniert wie auschecken eines Commits - nur mit der Tag-Bezeichnung anstelle der Prüfsumme
+Syntax: <code>git checkout <Tag></code>
+===== Branch =====
+  * Anzeigen, Löschen und Anlegen, Verwalten von Branches
+Branches listen:
+<code>
+git branch
+</code>
+Der Branch mit dem führenden * ist der aktuelle (im Working-Directory befindliche) Branch
+\\ \\
+Branche erstellen:
+<code>
+git branch <Name des Neuen Branches>
+</code>
+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:
+<code>
+git branch -m <Alter Name> <Neuer Name>
+</code>
+-m steht für move.
+\\ \\
+Branch löschen:
+<code>
+git branch -d <Branchname>
+</code>
+\\ \\
+Letzten Commit für alle Branches anzeigen:
+<code>
+git branch -v
+</code>
+\\ \\
+Alle gemergten Branches anzeigen (alle die die auf den gleichen Commit zeigen - dazu zählen auch die die noch gar nicht geändert wurden):
+<code>
+git branch --merged
+</code>
+\\ \\
+Alle nicht gemergten Branches anzeigen (alle die nicht auf den gleichen Commit wie der aktuelle Branch) zeigen:
+<code>
+git branch --no-merged
+</code>
+===== Checkout =====
+  * 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:
+<code>
+git checkout <Branchname>
+</code>
+Mit dem auschecken eines Branches wird dieser der aktive Branch - anschließende Commits werden in diesen gemacht
+\\ \\
+Commit auschecken:
+<code>
+git checkout <Commit-Checksumme>
+</code>
+**Achtung:** Oben stehende Methode checked in den aktuell aktiven Branch aus -> Commits werden diesem hinzugefügt
+Commit auschecken und neuen Branch mit diesem Beginnen:
+<code>
+git checkout -b <Commit-Checksum> <Branch-Name>
+</code>
+In diesem Fall wird auch gleich in den entsprechenden Branch gewechselt
+===== Merge =====
+  * Ü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:
+<code>
+git merge <Branch>
+</code>
+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.
+===== mergetool =====
+  * 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:
+<code>
+git mergetool
+</code>
+===== Checkout =====
+  *
+===== Rebase =====
+  * Ä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
+==== Squash ====
+  * Zusammenführen mehrerer (ungepushter) Commits zu einem
+<code>
+git rebase -i <Basis>
+</code>
+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

MyWiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge