Git

Organisatorische und technische Vorkehrungen, um sämtliche Produkte des Software-Prozess‘ konsistent (widerspruchsfrei) und kohärent (zusammenhängend) vorzuhalten

Ist eine ausgewiesene Konfiguration. Sie ist so zusammengestellt und geprüft, dass sie als stabil anzusehen ist. Als Ausgangspunkt für die weitere Entwicklung geeignet. KANN ein lauffähiges Gesamtsystem sein

Eine Konfiguration ist eine explizit gekennzeichnete und formal freigegebene Menge von SoftwareElementen, mit den jeweils gültigen Versionsangaben, die zu einem bestimmten Zeitpunkt im SoftwareLebenslauf in ihrer Wirkungsweise und ihren Schnittstellen aufeinander abgestimmt sind und gemeinsam eine vorgesehene Aufgabe erfüllen sollen.

Sobald an einer Working Copy gearbeitet wird protokolliert Git alle getätigten Änderungen mit. Mittels commit können die Änderungen zu dem Repository hinzugefügt werden, eine neue Version der Datei(n) befinden sich dann im Repo. Anschließend können verschiedene Versionen miteinander verglichen, Änderungen rückgängig oder zu einer früheren Version zurückgekehrt werden. Die Log-Informationen, die von Git mit aufgezeichnet werden können mit "git log" ausgegeben werden, "git status" listet die noch nicht ins Repo gespielten Änderungen der Working Copy auf.

_____________________

Durch Hashcodes (SHA-1) die den Dateiinhalt eindeutig charakterisieren: Gleicher Code = gleiche Dateiversion.

Dem Repository bereits bekannte Dateizustände werden nicht erneut gespeichert, sondern nur referenziert.

Ein Snapshot stellt den Projektzustand zum Zeitpunkt t dar.

Ich speichere immer die Information ab, die zu einer Version gehört. Bei unveränderten Dateien werden diese nicht redundant neu gespeichert, sondern es werden Datenstrukturen angelegt die repräsentativ für die Ursprungsdatei stehen.

Ist eine ausgewiesene Baseline

Ziel: Auslieferung an den Kunden. MUSS ein lauffähiges Gesamtsystem sein.

Durchführen eines Commit: Nimmt Dateien aus der Staging Area und speichert diesen Snapshot dauerhaft im Repository.

Es entsteht ein Commit-Tree.

1. Von allen Dateien die Committet werden sollen wird die blob <size> bestimmt und wird als Metadaten eingetragen -

2. Für jede Datei wird ein Hashcode bestimmt (Gibt Auskunft über den Inhalt ist aber nicht rekonstruierbar)

3. Diese Dateien werden nach dem HashCode umbenannt (Der normale Name geht verloren)

4. Es gibt eine weitere Datei das sogenannte „Tree Object“ (es steht wieder die tree <size> als Metadaten in der Datei. Diese Datei verweist auf einen blob mit der Hash-Code Nummer XYZZ und dieser blob heißt im wahren Leben z.b. „README“. Dadurch wird der eigentliche Dateiname gerettet, obwohl er im Repository keine Bedeutung hat

5. Neben dem Tree- Objekt gibt es noch eine Commit-Datei. Diese Commit Datei verweist auf das Tree-Objekt und beinhaltet Metadaten z.B. Autor und committer und die commit message

- Pro Commit entsteht ein ganzer Baum von Dateien (Commit Tree)

- Ein Commit enthält durch den Committer steuerbare Menge von Dateien

- Steuerung der Menge der Dateien durch Stage/Index

- Zusätzliche Dateien für Metadaten

Tracking: Eine Datei kann sich im Working Directory in 3 Zuständen befinden:

1. tracked

2. untracked

3. ignored

tracked: Die Datei wird beobachet. Änderungen an ihr werden zum Staging vorgeschlagen.

untracked: Git weiß noch nicht, ob Sie die Datei lieber tracken oder ignorieren würden.

ignored: Sie haben Git gegenüber explizit ein Tracking ausgeschlossen.

- 4 Zustände: Untracked, Unmodified, Modified, Staged

- Untracked: Ich habe eine neue Datei angelegt, die noch nicht an die Versionsverwaltung übergeben wurde (Datei wird nicht beobachtet)

- Staged: Wenn ich die Datei an die Versionsverwaltung übergebe führt das zu einer Operation „Add the file“. Dadurch nimmt die Datei einen neuen Zustand ein-> Staged.

- Unmodified: Wenn ich danach einen Commit mache ist die Datei in meinem Working Directory

- Modified: Wenn ich danach meine Datei editiere, ist meine Datei „Modified“

Erklärung rebase:

Bewege die Commits des aktuellen Branch, so das der Basis-Commit des aktuellen Branch dem angegebenen Punkt (Branch oder Commit) entspricht. Hierbei werden die SHA-1-Werte werden neu berechnet und es werden tatsächlich sogar neue Commits erstellt und die alten an Ort und Stelle belassen! Der gesamte feature-Branch wird zur Spitze des main-Branch verschoben und alle neuen Commits werden effektiv in den main-Branch integriert. Anstatt einen Merge-Commit zu nutzen, wird der Projektverlauf beim Rebasing neu geschrieben, indem für jeden Commit im originalen Branch völlig neue Commits erstellt werden

Merging:

Rebase:

Dateien werden von dem lokalen Repository in das Remote-Repository (Cloud) geladen

Übertragen von Remote zu Local Repository.

Pull ist Fetch mit anschließendem Merge des Remote Branch in den aktuellen Local Branch.

Zusammenführen unterschiedlicher Branches

Repository ist ein Verzeichnis, das mit Git verwaltet wird. Dieses beinhaltet die History, die verschiedenen Versionen der Software und verschiedene Branches.

Beim Einsatz von Git dienen Branches (engl.: to branch - sich verzweigen) dazu, um einen separaten Arbeitszweig zu erstellen. Dieser kann dann auch als neuer Kontext gesehen werden, in dem gearbeitet wird. So kann z.B. die Programmierung eines Sicherheits-Patches in einem eigenen Branch erfolgen (im Kontext des Patches), der bei Fertigstellung und nach dem Testen zurück in den Master-Zweig eingearbeitet wird.

Init erstellt in einem bestehenden Projektverzeichnis ein rudimentäres Repository. Dieses befindet sich in dem Unterverzeichnis .git.

add-Befehl fügt benannte Dateien zum Index hinzu

2. Folgender Commit transferiert den dann geltenden Zustand der Datei ins Repository.

Erstelle einen Snapshot der auf dem Index befindlichen Dateien und überführe diesen Snapshot in das Repository

Wechsele den aktuellen Branch.

Effekte: 1. „Head“ wird verschoben

2. Das Working Directory wird so angepasst, dass es dem ausgecheckten Commit entspricht.

Erstelle einen eigenen, benannten Arbeitsbereich.

Ein Fast-Forward-Merge findet statt, wenn ein linearer Pfad von der Spitze des aktuellen Branches zum Ziel-Branch existiert. Statt die Branches tatsächlich zusammenzuführen, muss Git zur Integration der verschiedenen Verläufe lediglich die Spitze des aktuellen Branches an die Spitze des Ziel-Branches verschieben ("fast-forward"). Dadurch werden die Verläufe miteinander kombiniert, und alle Commits aus dem Ziel-Branch sind auch über den aktuellen Branch zugänglich.

Beispiel:

Lisa hat den master-Branch in ihren persönlichen Branch gemerged. Danach schafft sie leider nicht mehr viel und will ihren Lisa-Branch vor Feierabend in den masterBranch mergen, damit die Kollegen z.B. morgen früh darauf gleich wieder aufsetzen können. Da C5 den Commit C4 als direkten Vorgänger hat und keine weiteren Commits beteiligt sind, kann der HEAD von master einfach auf C5 gesetzt werden. Dies ist bei FFMergea) die einzige Änderung im Repository.

Markiere den aktuellen Commit mit einem Tag.

Setze den HEAD des aktuellen Branch zurück auf einen Vorgänger-Commit.

Vorteile: wenige Merge Conflicts

Änderungen sind noch im Gedächtnis.

Kollegen können frühzeitig auf Basis von Änderungen ihre Arbeit fortsetzen und investieren nicht unnötig Arbeitszeit.

Nachteile: Risiko, dass nichtlauffähiger Code von Anderen übernommen wird und so deren Arbeit behindert

Dient zum Kennzeichnen von Auslieferungszuständen (Version und Empfänger). Z.B um einen bestimmten Zustand als wichtig zu makieren.

Der Inhalt von Dateien liegt für Git auf drei Ebenen, dem Working Tree, dem Index und dem Repository.

Der Working Tree entspricht den Dateien, wie sie auf dem Dateisystem Ihres Arbeitsrechners liegen – wenn Sie also Dateien mit einem Editor bearbeiten, mit grep darin suchen etc., operieren Sie immer auf dem Working Tree.

Source Code Management-System, dass zur Versionsverwaltung eines Software Entwicklungsprojekte dient.

GitHub ist ein Onlinedienst, der Software-Entwicklungsprojekte auf seinen Servern bereitstellt

Commits bilden die Grundbausteine einer Git-Projektzeitleiste. Sie sind quasi Snapshots oder Meilensteine in der Zeitleiste eines Git-Projekts.

Snapshots werden per Commit in das lokale Repository übertragen, ohne dass irgendeine Interaktion mit anderen Git-Repositorys erforderlich ist. Git-Commits können später in beliebige Remote-Repositorys gepusht werden.

Repository ist ein Verzeichnis, das mit Git verwaltet wird. Dieses beinhaltet die History, die verschiedenen Versionen der Software und verschiedene Branches.

Tag: dient zum Kennzeichnen von Auslieferungszuständen (Version und Empfänger). Z.B um einen bestimmten Zustand als wichtig zu makieren.

Commit: Commits stellen sogenannte Snapshots eines Projekts dar. Dabei sichert Git den Zustand sämtlicher Dateien in diesem Moment und speichert eine Referenz auf diesen Snapshot, durch ein SHA1-Hash als Prüfsumme. Außerdem werden unveränderte Dateien nicht von GIT kopiert, sondern lediglich eine Verknüpfung zu der vorherigen Version der Datei angelegt. (snapshot: Projektzustand zum Zeitpunkt t)

Branch: Ist eine Abzweigung von der Hauptentwicklungslinie, in der unabhängig vom Hauptzweig weitergearbeitet werden kann. Wird verwendet um verschiede Funktionen unabhängig voneinander zu entwickeln. In einem Repository besteht immer ein Master Branch. Bsp. Beta Version und stabile Version. Branching = Variantenbildung.

Fork: Ist ein Ableger eines gesamten Repositorys. Dieses beinhaltet somit alle Branches. In dieser Gabelung des eigentlichen Repositorys kann jeder vor sich hin entwickeln und diese am Ende wieder zum ursprünglichen Repository zusammenführen.

Merge: Zusammenführen von unterschiedlichen Branches

Was ist ein Commit Tree? Ein Commit enthält eine durch den Committer steuerbare Menge an Dateien. Pro Commit entsteht somit ein ganzer Baum von Dateien! Besteht aus TreeObjects und Blops(einzelne Elemente z.B.Klasse)

Working-Tree: Ein Local Repository liefert eine Sammlung von Dateien, welche bestimmte Versionen beinhaltet.

Die meisten anderen Systeme speichern Information als eine fortlaufende Liste von Änderungen an Dateien („Diffs“). Diese Systeme (CVS, Subversion, Perforce, Bazaar usw.) betrachten die Informationen, die sie verwalten, als eine Menge von Dateien und die Änderungen, die über die Zeit hinweg an einzelnen Dateien vorgenommen werden.

Git sieht Daten eher als eine Reihe von Snapshots eines Mini-Dateisystems. Bei jedem Commit (d.h. den gegenwärtigen Status Deines Projektes als eine Version in Git speicherst), sichert Git den Zustand sämtlicher Dateien in diesem Moment („Snapshot“) und speichert eine Referenz auf diesen Snapshot.

„Committed“ bedeutet, dass die Daten in der lokalen Datenbank gesichert sind.

„Modified“ bedeutet, dass die Datei geändert, aber noch nicht committed wurde.

„Staged“ bedeutet, dass eine geänderte Datei in ihrem gegenwärtigen Zustand für den nächsten Commit vorgemerkt ist. Datei befindet sich in Staging Area.

das Git Repository, Git Workspace und die Staging Area.

• Commit ID (SHA-1 Hash)

• Tree object: ID

• Author: X

• Commiter: X

• Commit Message: Y

add fügt benannte Dateien zum Index hinzu. (auch Staging genannt)

checkout Wechsele den aktuellen Branch.

tag Markiere den aktuellen Commit mit einem Tag. Kennzeichnen von Auslieferungszuständen (Version und Empfänger)

reset Setze den HEAD des aktuellen Branch zurück auf einen Vorgänger-Commit.

rebase Bewege die Commits des aktuellen Branch, so das der Basis-Commit des aktuellen Branch, dem angegebenen Punkt (Branch oder Commit) entspricht.

clone wenn man eine Kopie eines bereist existierenden Repositories anlegen will (jede Version jeder Datei in der Historie wird heruntergeladen)

1. Modifikation von Datein im WorkingDirectory

2. Staging der Datein durch Hinzufügen von Snapshots er datein zur Staging Area

3. Durchführen eines Commits: Nimmt Dateien aus Staging Area udn speichert Snapshot dauerhaft im Repository

Um das lokale Repository mit den neuesten Anderungen zu aktualisieren wird der Befehl Pull verwendet, Git lädt dadurch zuerst eine Arbeitskopie herunter und führt sie dann mit dem eigenen Stand zusammen (merge). Hier wird also Fetch und Merge zusammen verwendet.

Lokales Repository speichert die Anderungen vom remote Repository aber ohne in den eigenen Branch zu mergen. Also sozusagen wie ein Pull ohne merge.

Zusammenführen von unterschiedlichen Branches.

Eine Datei kann sich gegenüber Git in 3 Zuständen befinden.

tracked: Die Datei wird beobachtet. Änderungen an ihr werden zum Staging vorgeschlagen.

untracked: Git weiß noch nicht, ob Sie die Datei lieber tracken oder ignorieren würden.

ignored die Datei ist für das ein Tracking explizit ausgeschlossen.

! Kann in .gitignore Datei angegeben werden

Ausschließen von bestimmten Dateien. z.B. Cache Dateien. Diese werden von GIT nicht versioniert.