faecher:informatik:oberstufe:git:versionsgeschichte:start []

Diese Seite ist nicht editierbar. Du kannst den Quelltext sehen, jedoch nicht verändern. Kontaktiere den Administrator, wenn du glaubst, dass hier ein Fehler vorliegt.
====== Versionsgeschichte und Zeitmaschine ======

===== Die Abfolge der Commits betrachten =====

Nachdem wir einige Commits gemacht haben, können wir unser Repository untersuchen:

<code bash>
max@pc:~/tagebuch$ git log
commit d7aaac47e7e68c5dcbacb4f1b8fa5a1ba4377348 (HEAD -> main)
Author: Max Mustermann <max@example.org>
Date:   Wed Oct 2 09:12:06 2024 +0200

    Mittagessen hinzugefügt

commit adc15c234c635a79a1cf90d10199ed6e42b47954
Author: Max Mustermann <max@example.org>
Date:   Wed Oct 2 09:11:12 2024 +0200

    fruehstueck.txt geändert

commit f9353d6278296bd173d3760e3b95e743208650e7
Author: Max Mustermann <max@example.org>
Date:   Wed Oct 2 08:58:45 2024 +0200

    Frühstück in Datei 'fruehstueck.txt' hinzugefügt

commit 28ec5a71bc2bce75bbbbfe5f2d336fe49b3642fa
Author: Max Mustermann <max@example.org>
Date:   Wed Oct 2 08:35:53 2024 +0200

    Erster Commit: aufstehen.txt angelegt
</code> 

Man sieht -- recht ausführlich -- einige Informationen zu jedem Zeitpunkt, an dem ein Snapshot der unter Versionskontrolle stehenden Dateien in unserem Arbeitsverzeichnis erstellt wurde:

  * Die Hashsumme des Commits (die ersten 7 Zeichen identifizieren einen Commit eindeutig)
  * Der Autor
  * Datum und Zeit, zu der der Snapshot erstellt wurde

Das ganz benötigt recht viel Platz, man kann die Ausgabe des Logs umfangreich anpassen, zum Beispiel so:

<code bash>
max@pc:~/tagebuch$ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%ci) %Creset' --abbrev-commit
* d7aaac4 - (HEAD -> main) Mittagessen hinzugefügt (2024-10-02 09:12:06 +0200) 
* adc15c2 - fruehstueck.txt geändert (2024-10-02 09:11:12 +0200) 
* f9353d6 - Frühstück in Datei 'fruehstueck.txt' hinzugefügt (2024-10-02 08:58:45 +0200) 
* 28ec5a7 - Erster Commit: aufstehen.txt angelegt (2024-10-02 08:35:53 +0200)
</code>

Das sieht zwar nett aus, es ist aber ein wenig schwer, sich all die Optionen zu merken. git ermöglicht es darum, für solche individuellen Befehle sogenannte **Aliase** anzulegen -- auf die folgende Weise kann man einen eigenen "git-Befehl" anlegen, der die Versionsgeschichte hübsch ausgibt.

<code bash>
max@pc:~/tagebuch$ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %Creset' --abbrev-commit"
max@pc:~/tagebuch$ git lg
* d7aaac4 - (HEAD -> main) Mittagessen hinzugefügt (vor 6 Minuten) 
* adc15c2 - fruehstueck.txt geändert (vor 7 Minuten) 
* f9353d6 - Frühstück in Datei 'fruehstueck.txt' hinzugefügt (vor 19 Minuten) 
* 28ec5a7 - Erster Commit: aufstehen.txt angelegt (vor 42 Minuten) 
</code>



----
{{:aufgabe.png?nolink  |}}
=== (A1) ===

  * Was hat sich zwischen der Ausgabe des ersten log-Befehls und der, mit dem angelegten Alias verändert?
  * Mit ''git log %%--%%help'' kann man sich die Hilfe zu ''git log'' anzeigen lassen, das funktioniert auch mit anderen git-Befehlen. Kannst du die Platzhalter für die Ausgabe mit ''%%-%%-pretty=format:'' in der Hilfe finden?

===== Zeitmaschine =====

==== Go Back in Time - es gibt offene Fragen... ====

<callout type="warning" title="Wichtig">
Zunächst ist es sehr empfehlenswert, dass man nur dann zu einem älteren Stand der Dateien zurückkehrt, wenn das Arbeitsverzeichnis **keine nicht committeten Änderungen** beinhaltet. ("Sauberes Arbeitsverzeichnis")
</callout>

Wir befinden uns aktuell also in einem sauberen Arbeitsverzeichnis, ''git status'' zeigt also keine unbearbeiteten Änderungen:

<code bash>
max@pc:~/tagebuch$ git status
Auf Branch main
nichts zu committen, Arbeitsverzeichnis unverändert
</code>

Jetzt können wir mit unserem neuen Alias ''git lg'' die Versionsgeschichte ansehen:

<code bash>
max@pc:~/tagebuch$ git lg
* d7aaac4 - (HEAD -> main) Mittagessen hinzugefügt (vor 6 Minuten) 
* adc15c2 - fruehstueck.txt geändert (vor 7 Minuten) 
* f9353d6 - Frühstück in Datei 'fruehstueck.txt' hinzugefügt (vor 19 Minuten) 
* 28ec5a7 - Erster Commit: aufstehen.txt angelegt (vor 42 Minuten) 
</code>

Man kann den Zustand des Arbeitsverzeichnisses aus den Commits wieder herstellen. Es ist also möglich, das Arbeitsverzeichnis in genau den Zustand zurückzuversetzen, in dem es beim Commit ''f9353d6 - Frühstück in Datei 'fruehstueck.txt' hinzugefügt'' vor 19 Minuten war -- oder eben zu jedem anderen Zeitpunkt, an dem ich zuvor den Zustand des Arbeitsverzeichnisses als Snapshot commitet habe. Der Befehl dazu ist ''git checkout <Commit-Hash>'':

<code bash>
max@pc:~/tagebuch$ git checkout f9353d6 
Hinweis: Wechsle zu 'f9353d6'.

Sie befinden sich im Zustand eines 'losgelösten HEAD'. Sie können sich
umschauen, experimentelle Änderungen vornehmen und diese committen, und
Sie können alle möglichen Commits, die Sie in diesem Zustand machen,
ohne Auswirkungen auf irgendeinen Branch verwerfen, indem Sie zu einem
anderen Branch wechseln.

Wenn Sie einen neuen Branch erstellen möchten, um Ihre erstellten Commits
zu behalten, können Sie das (jetzt oder später) durch Nutzung von
'switch' mit der Option -c tun. Beispiel:

  git switch -c <neuer-Branchname>

Oder um diese Operation rückgängig zu machen:
  git switch -

Sie können diesen Hinweis ausschalten, indem Sie die Konfigurationsvariable
'advice.detachedHead' auf 'false' setzen.

HEAD ist jetzt bei f9353d6 Frühstück in Datei 'fruehstueck.txt' hinzugefügt
</code>

Was ist denn jetzt passiert? Was bedeutet diese komische Meldung? Was ist ein ''lösgelöster HEAD''((Auf Englisch ''detached HEAD''))?

**(1)** Zunächst einmal befinden sich die Dateien im Verzeichnis jetzt in dem Zustand, in dem sie waren, als der Commit ''f9353d6'' erstellt wurde. Überprüfe das! 
++++ Lösung |
Man erkennt, dass die Datei mitagessen.txt noch nicht vorhanden war, und auch der Inhalt der anderen Dateien entspricht dem Stand zu dem Zeitpunkt als der Commit gemacht wurde.
<code bash>
max@pc:~/tagebuch$ ls
aufstehen.txt  fruehstueck.txt  mittagessen.txt
max@pc:~/tagebuch$ git checkout f9353d6
Hinweis: Wechsle zu 'f9353d6'.
[... Meldunden zum losgelösten HEAD ausgelassen ...]
HEAD ist jetzt bei f9353d6 Frühstück in Datei 'fruehstueck.txt' hinzugefügt
frank@pike:~/tagebuch$ ls
aufstehen.txt  fruehstueck.txt
</code>
++++

**(2)** Untersuche die Versionsgeschichte -- wie sieht diese jetzt aus? Was fällt auf?
++++ Lösung |
<code>
max@pc:~/tagebuch$ git lg
* f9353d6 - (HEAD) Frühstück in Datei 'fruehstueck.txt' hinzugefügt (vor 11 Stunden) 
* 28ec5a7 - Erster Commit: aufstehen.txt angelegt (vor 11 Stunden)
</code>

Es fällt auf, dass die Commits die neuer sind als ''f9353d6'' irgendwie "verschwunden sind"??!!
++++

Git zeigt mit ''git log'' standardmäßg die Versionsgeschichte an, die zu dem Commit geführt hat den man im Arbeitsverzeichnis gerade angezeigt bekommt. Um git zu veranlassen, die **gesamte** Versionsgeschichte anzuzeigen, muss man dem Befehl ''git log'' die Option ''%%--all%%'' mitgeben.

<code bash>
max@pc:~/tagebuch$ git lg --all
* d7aaac4 - (main) Mittagessen hinzugefügt (vor 10 Stunden) 
* adc15c2 - fruehstueck.txt geändert (vor 10 Stunden) 
* f9353d6 - (HEAD) Frühstück in Datei 'fruehstueck.txt' hinzugefügt (vor 11 Stunden) 
* 28ec5a7 - Erster Commit: aufstehen.txt angelegt (vor 11 Stunden) 
</code>

==== Was ist HEAD? ====

Man muss sich die Versionsgeschichte als (verzweigte) Abfolge von Commits vorstellen, die jeweils durch ihre Commit-ID identifiziert werden. Manche Commit-IDs bekommen **Namen**: **Diese benannten Commits sind "Branches" und  "Tags".** Man spricht von "Referenzen auf Commits".

{{ :faecher:informatik:oberstufe:git:versionsgeschichte:head.png?30|}}
Eine besondere Referenz ist ''HEAD''. HEAD springt in gewisser Weise in der Versionsgeschichte herum, und zeigt immer auf denjenigen Commit, der im Arbeitsverzeichniss gerade "ausgecheckt" ist. 

Der Zustand in unserem Beispiel ist "in bunt" folgender:

{{ :faecher:informatik:oberstufe:git:versionsgeschichte:commits.drawio.png|}}

Es gibt insgesamt also 4 Commits, das Arbeitsverzeichnis ist im Zustand von Commit ''f9353d6'' darum zeigt ''HEAD'' auf diesem Commit. Außerdem gibt es den Branch ''main'', das ist eine benannte Referenz auf den neuesten Commit mit der ID ''d7aaac4''

Um die Situation des "Lösgelösten HEAD" zu verstehen, muss man sich nun klar machen, dass der Commit ''adc15c2'' auf dem Commit ''f9353d6'' (auf den derzeit HEAD zeigt) basiert. Wenn man im derzeitigen Zustand des Arbeitsverzeichnisses etwas ändert, bekommt man ein Problem, da diese Beziehung ''adc15c2'' basiert auf ''f9353d6'' nicht mehr eindeutig interpretierbar ist: Wo sortiert sich der ausgehend von ''f9353d6'' veränderte Zustand des Arbeitsverzeichnisses in die Versionsgeschichte ein wenn man einen neuen Commit erzeugt? 

Diese Situation wird als "detached HEAD" oder losgelöster HEAD bezeichnet. Man kann sich umsehen und Dinge ändern, wenn man anschließend jedoch wieder in der Versiongeschichte "springt" gehen diese Änderungen verloren oder landen in einem Commit der "losgelöst" ist, also nicht in einem Branch innerhalb der Versionsgeschichte enthalten ist - und das sollte man vermeiden, da man solche Commits später nur schwer wiederfinden kann.

----
{{:aufgabe.png?nolink  |}}
=== (A2) ===

  * Wechsle mit dem Befehl ''git checkout <Commit-ID>'' zu unterschiedlichen Versionen deines Tagebuchs und schau dich um, ohne etwas zu ändern. Lasse dir jeweils die vollständige Versionsgeschichte anzeigen und beobachte, wie der HEAD in der Versionsgeschichte springt.
  * Wechsle zur Commit ID des neuesten Commits. Wechsle dann zum Branch ''main'' indem du ''main'' auscheckst. Verhält sich git in beiden Fällen gleich?
  * Gehe in der Zeit zurück zu einem älteren Commit. Verändere eine Datei. Versuche wieder in der Zeit zu springen. Was passiert? 
  * Mit der Option ''-f'' kann man git zwingen, einen Checkout zu machen, bei dem Änderungen verloren gehen. Springe von deinem geänderten Zeitpunkt unter Datenverlust zurück zu ''main'' und dann wieder zu dem Commit den du zuvor geändert hattest. Überprüfe, dass deine Änderungen tatsächlich verloren gegangen sind.
  * Wir wissen ja, dass man sich Änderungen am einfachsten merkt, wenn man einen Commit erstellt. Ändere erneut eine Datei und erstelle einen neuen Commit, springe dann zurück zu ''main''. Was passiert jetzt? Warum ist das ungünstig? 
 
++++ Demonstration der Aufgabenstellung |
<html>
<iframe title="Git Zeitmaschine - Demo zur Aufgabe" src="https://tube.schule.social/videos/embed/331c768e-c7fa-45ff-abf3-d0d564976f5f" allowfullscreen="" sandbox="allow-same-origin allow-scripts allow-popups allow-forms" width="560" height="315" frameborder="0"></iframe>
</html>

https://tube.schule.social/w/7j4D8jKaiHZTDKAMGfmv1c

++++

Mit dem letzten Befehl ''git branch blaubeerfruehstueck f98e6d1'' im Video wurde ein neuer Branch angelegt. In der Ausgabe von ''git log %%--all%%'' kann man das erkennen - es gibt im Zeitverlauf jetzt eine **Verzweigung**.

{{ :faecher:informatik:oberstufe:git:versionsgeschichte:2024-10-07_19-24.png |}}