Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:git:neuanfang:start [24.09.2024 17:10] – [Zurück und mit einem weiteren Branch weiterarbeiten - die bisherigen Änderung bleiben erhalten] Frank Schiebel
+++ faecher:informatik:oberstufe:git:neuanfang:start [17.03.2025 18:18] (aktuell) – [Zurück und mit einem weiteren Branch weiterarbeiten - die bisherigen Änderung bleiben erhalten] Frank Schiebel
@@ Zeile 15: / Zeile 15: @@
 <callout type="danger" icon="true">
-Dieses Vorgehen ist eine der (wenigen) Möglichkeiten in git tatsächlich **Informationen unwiederbringlich zu verlieren**. Man sollte sich also wirklich sicher sein, dass man die Änderungen, die man nach dem Zeitpunkt, zu dem man zurückkehren möchte nicht mehr benötigt.
+Dieses Vorgehen ist eine der (wenigen) Möglichkeiten in git tatsächlich **Informationen, die sich bereits in einem Commit befinden, unwiederbringlich zu verlieren**. Man sollte sich also wirklich sicher sein, dass man die Änderungen, die man nach dem Zeitpunkt, zu dem man zurückkehren möchte nicht mehr benötigt.
 </callout>
-Zur Verdeutlichung dieses Situation habe ich jetzt noch eine weitere neue Datei angelegt - diese heißt wieder ''mittagessen.txt'', steht aber noch nicht unter Versionsverwaltung.
+Zur Verdeutlichung dieser Situation habe ich jetzt noch eine weitere neue Datei angelegt - diese heißt wieder ''mittagessen.txt'', steht aber noch nicht unter Versionsverwaltung.
 <code bash>
@@ Zeile 35: / Zeile 35: @@
 </code>
-Mit dem Befehl ''git reset --hard 2c70b75'' bringt man alle Dateien im Verzeichnis, die unter Versionskontrolle stehen auf den Stand, die diese zum Zeitpunkt des Commits 2c70b75 hatten. Alle späteren Änderungen und die spätere Versionsgeschichte gehen unwiderruflich verloren! Dateien, die //nicht// unter Versionskontrolle stehen, werden  nicht beeinflusst.
+Mit dem Befehl ''git reset %%--%%hard 2c70b75'' bringt man alle Dateien im Verzeichnis, die unter Versionskontrolle stehen auf den Stand, die diese zum Zeitpunkt des Commits 2c70b75 hatten. **Alle späteren Änderungen und die spätere Versionsgeschichte gehen unwiderruflich verloren!** Dateien, die //nicht// unter Versionskontrolle stehen, werden  nicht beeinflusst.
 Das sieht dann so aus:
@@ Zeile 52: / Zeile 52: @@
 </code>
-  * Die Dateien ''aufstehen.txt'' und ''fruehstueck.txt'' sehen jetzt so aus, wie sie zum Zeitpunkt es Commits aussahen
+  * Die Dateien ''aufstehen.txt'' und ''fruehstueck.txt'' sehen jetzt so aus, wie sie zum Zeitpunkt des Commits aussahen
   * Die Datei ''mittagessen.txt'' ist unverändert, weil sie nicht unter Versionskontrolle stand
   * ''git log'' zeigt auch mit der Option ''%%--all%%'' die Commits, die nach ''2c70b75'' gemacht wurden nicht mehr an - diese Daten sind verloren.
@@ Zeile 118: / Zeile 118: @@
 Man sieht, dass HEAD auf den Branch ''Neuer_Versuch'' zeigt - wir arbeiten also derzeit nicht mehr auf ''main''. Das macht zunächst nichts aus, wenn sich die neuen Änderungen bewähren, möchte man aber eventuell den neuen Branch als neuen ''main'' Branch verwenden - wie geht das?
+**Anmerkung:** Man kann selbstverständlich auch einfach auf dem neuen Branch weiter arbeiten und den nächsten Schritt auslassen. Wenn man das Vorgehen dann aber später wiederholt, weil man wieder in der Zeit zurückgehen möchte bekommt man jedes mal einen neuen Branch, das ist "unschön".
@@ Zeile 128: / Zeile 130: @@
   * Man stellt sicher, dass man sich auf dem neuen Branch befindet: ''git checkout Neuer_Versuch'', sehr wahrscheinlich erhält man die Meldung, dass man sich bereits auf dem neuen Branch befindet.
   * Die Situation ist dann folgendermaßen - wir arbeiten auf dem Branch ''Neuer_Versuch'': {{ :faecher:informatik:oberstufe:git:neuanfang:2024-09-24_17-32.png |}}
-  * Nun führt man einen sogenannten "Merge" durch, der den ''main'' Branch mit unserem "Neuen_Versuch" zusammenführt. Weil wir bei dieser ZUsammenführung unsere Änderungen auf jeden Fall behalten wollen, verwenden wir als "Zusammenführungsstrategie" die Option ''%%--strategy=ours%%'', also "unsere" Änderungen gewinnen immer. Der gesamte Befehl sieht dann so aus: ''git merge--strategy=ours main'', Anschließend sieht das Repo so aus:  {{ :faecher:informatik:oberstufe:git:neuanfang:2024-09-24_17-39.png |}} Man sieht, dass die Branches jetzt zwar zusammengeführt sind, aber ''main'' zeigt noch immer auf den alten Commit.
+  * Nun führt man einen sogenannten "Merge" durch, der den ''main'' Branch mit unserem "Neuen_Versuch" zusammenführt. Weil wir bei dieser Zusammenführung unsere Änderungen auf jeden Fall behalten wollen, verwenden wir als "Zusammenführungsstrategie" die Option ''%%--strategy=ours%%'', also "unsere" Änderungen gewinnen immer. Der gesamte Befehl sieht dann so aus: ''git merge %%--strategy=ours%% main'', Anschließend sieht das Repo so aus:  {{ :faecher:informatik:oberstufe:git:neuanfang:2024-09-24_17-39.png |}} Man sieht, dass die Branches jetzt zwar zusammengeführt sind, aber ''main'' zeigt noch immer auf den alten Commit.
   * Um das zu beheben checkt man jetzt ''main'' aus und führt dann den neuen Branch mit main zusammen: ''git checkout main'' -- jetzt ist HEAD auf ''main''. Jetzt mit ''git merge Nuer_Versuch'' den neuen Branch nach ''main'' zusammenführen, dann sieht das Ergebnis so aus: {{ :faecher:informatik:oberstufe:git:neuanfang:2024-09-24_19-05.png |}}
   * Wenn man jetzt neue Commits anfügt, finden diese im ''main'' Branch statt. Der Commit ''a5c28ad5b'', bei dem es Schokolade zum Frühstück gab, bleibt erhalten. {{ :faecher:informatik:oberstufe:git:neuanfang:2024-09-24_19-10.png |}}