| Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige Überarbeitung |
| faecher:informatik:oberstufe:git:neuanfang:start [08.10.2024 06:41] – [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 |
|---|
| </callout> | </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> | <code bash> |
| </code> | </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: | Das sieht dann so aus: |
| </code> | </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 | * 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. | * ''git log'' zeigt auch mit der Option ''%%--all%%'' die Commits, die nach ''2c70b75'' gemacht wurden nicht mehr an - diese Daten sind verloren. |
| * 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. | * 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 |}} | * 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 |}} | * 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 |}} | * 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 |}} |