mirror of
https://github.com/pcottle/learnGitBranching.git
synced 2025-07-04 19:54:29 +02:00
More levels translated, only 9 more to go
This commit is contained in:
Jens Bremmekamp
parent
abb249b3ed
commit
a6a96569bf
6 changed files with 363 additions and 21 deletions
|
|
@ -3,10 +3,12 @@ exports.level = {
|
|||
"solutionCommand": "git clone;git fakeTeamwork;git commit;git pull --rebase;git push",
|
||||
"startTree": "{\"branches\":{\"master\":{\"target\":\"C1\",\"id\":\"master\",\"remoteTrackingBranchID\":null,\"localBranchesThatTrackThis\":null}},\"commits\":{\"C0\":{\"parents\":[],\"id\":\"C0\",\"rootCommit\":true},\"C1\":{\"parents\":[\"C0\"],\"id\":\"C1\"}},\"HEAD\":{\"target\":\"master\",\"id\":\"HEAD\"}}",
|
||||
"name": {
|
||||
"en_US": "Diverged History"
|
||||
"en_US": "Diverged History",
|
||||
"de_DE": "Abweichende History"
|
||||
},
|
||||
"hint": {
|
||||
"en_US": "check out the ordering from the goal visualization"
|
||||
"en_US": "check out the ordering from the goal visualization",
|
||||
"de_DE": "Beachte die Reihenfolge in der Zieldarstellung"
|
||||
},
|
||||
"startDialog": {
|
||||
"en_US": {
|
||||
|
|
@ -151,6 +153,149 @@ exports.level = {
|
|||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
"de_DE": {
|
||||
"childViews": [
|
||||
{
|
||||
"type": "ModalAlert",
|
||||
"options": {
|
||||
"markdowns": [
|
||||
"## Abweichende Inhalte",
|
||||
"",
|
||||
"Bisher haben wir gesehen wie man per `pull` Commits von Anderen ins lokale Repository holt und die eigenen Änderungen in ein entferntes `push`t. Ist doch ziemlich einfach, wie kann man da durcheinander kommen?",
|
||||
"",
|
||||
"Die Schwierigkeiten entstehen, wenn die History der beiden Repositorys *divergieren*, also voneinander abweichen. Bevor wir die Einzelheiten besprechen, schauen wir uns ein Beispiel an ...",
|
||||
""
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "ModalAlert",
|
||||
"options": {
|
||||
"markdowns": [
|
||||
"Stellt dir vor du holst dir Montags ein Repository per `clone` und fängst an, an einem Feature zu arbeiten. Bis Freitag soll es fertig und veröffentlicht sein -- doch, oh je! Deine Kollegen haben eine Menge Code während der Woche geschrieben, der dein Feature hat veralten lassen (und überflüssig gemacht hat). Sie haben diesen Code außerdem zum entfernten Repository gepusht, und dadurch basiert *deine* harte Arbeit jetzt auf einer *alten* Version des Projektes, die nicht länger relevant ist.",
|
||||
"",
|
||||
"In diesem Fall ist ein `git push` problematisch. Wenn du es ausführst, soll Git das entfernte Repository in den Zustand von Montag zurückversetzen? Soll es versuchen deinen Code auf die aktuelle Version zu packen? Oder soll es deine Änderungen einfach ignorieren, weil sie total veraltet sind?",
|
||||
"",
|
||||
"Da es in dieser Situation so viele Mehrdeutigkeiten gibt (da die Historys divergent sind) erlaubt Git dir nicht, deine Änderungen einfach zu `push`en. Es zwingt dich, zuerst die neuesten Änderungen vom Server zu holen und in deine zu integrieren bevor du deine Arbeit mit anderen teilen kannst."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "GitDemonstrationView",
|
||||
"options": {
|
||||
"beforeMarkdowns": [
|
||||
"Bla bla bla. Schauen wir uns das lieber in Aktion an:"
|
||||
],
|
||||
"afterMarkdowns": [
|
||||
"Siehst du? Nichts passiert, weil der Befehl fehlschlägt. `git push` schlägt fehl, weil der neueste Commit `C3` auf dem Commit `C1` auf dem Remote basiert. Der entfernte Server hat mittlerweile jedoch `C2` gepusht bekommen, also lässt Git deinen Push jetzt nicht mehr zu."
|
||||
],
|
||||
"command": "git push",
|
||||
"beforeCommand": "git clone; git fakeTeamwork; git commit"
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "ModalAlert",
|
||||
"options": {
|
||||
"markdowns": [
|
||||
"Wie sollen wir das auflösen? Es ist ganz einfach, du musst deinen Commit nur von der aktuellsten Version des Remotes ableiten.",
|
||||
"",
|
||||
"Es gibt verschiedene Möglichkeiten wie man das erreichen kann, aber die offensichtlichste ist es, deine Commits per Rebase zu verschieben. Schauen wir mal wie das abläuft:"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "GitDemonstrationView",
|
||||
"options": {
|
||||
"beforeMarkdowns": [
|
||||
"Also wenn wir vor dem Push erst mal einen Rebase mache ..."
|
||||
],
|
||||
"afterMarkdowns": [
|
||||
"Bämm! Wir haben unsere lokale Abbildung des entfernten Repositorys mit `git fetch` auf den neuesten Stand gebracht, unsere Arbeit auf die neueste Version des Remotes drauf gepackt und dann mit `git push` auf den Server geschoben."
|
||||
],
|
||||
"command": "git fetch; git rebase o/master; git push",
|
||||
"beforeCommand": "git clone; git fakeTeamwork; git commit"
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "ModalAlert",
|
||||
"options": {
|
||||
"markdowns": [
|
||||
"Gibt es noch weitere Möglichkeiten deine Arbeit zu aktualisieren wenn das entfernte Repository neue Commits bekommen hat? Klar! Schauen wir uns dasselbe an, aber diesmal arbeiten wir mit `merge`.",
|
||||
"",
|
||||
"Obwohl `git merge` deine Arbeit nicht verschiebt (und stattdessen einen Merge Commit erzeugt) ist es eine Möglichkeit Git dazu zu bringen, alle Änderungen vom Remote in deine Sachen zu integrieren. Denn durch den Merge wird der Remote Branch zu einem *Vorgänger* deines Branches, was bedeutet dass dein Commit alle Commits des entfernten Branches beinhaltet.",
|
||||
"",
|
||||
"Zur Demonstration ..."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "GitDemonstrationView",
|
||||
"options": {
|
||||
"beforeMarkdowns": [
|
||||
"Wenn wir nun also mergen anstatt einen Rebase zu machen ..."
|
||||
],
|
||||
"afterMarkdowns": [
|
||||
"Ok. Wir haben die lokale Abbildung des entfernen Repositorys mit `git fetch` aktualisiert, die neuen Änderungen per *Merge* in deine integriert, und letztere dann mit `git push` auf den Server gebracht."
|
||||
],
|
||||
"command": "git fetch; git merge o/master; git push",
|
||||
"beforeCommand": "git clone; git fakeTeamwork; git commit"
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "ModalAlert",
|
||||
"options": {
|
||||
"markdowns": [
|
||||
"Wahnsinn! Kann ich das auch irgendwie machen ohne soviel zu tippen?",
|
||||
"",
|
||||
"Na klar -- du kennst ja schon `git pull` als Zusammenfassung von `fetch` und `merge`. Praktischerweise bringt man es mit der Option `--rebase` dazu, anstatt des Merge einen Rebase zu machen.",
|
||||
"",
|
||||
"Gucken wir uns das mal an."
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "GitDemonstrationView",
|
||||
"options": {
|
||||
"beforeMarkdowns": [
|
||||
"Zunächst `git pull --rebase` ..."
|
||||
],
|
||||
"afterMarkdowns": [
|
||||
"Genau wie vorher! Nur viel kürzer."
|
||||
],
|
||||
"command": "git pull --rebase; git push",
|
||||
"beforeCommand": "git clone; git fakeTeamwork; git commit"
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "GitDemonstrationView",
|
||||
"options": {
|
||||
"beforeMarkdowns": [
|
||||
"Und nun das normale `git pull` ..."
|
||||
],
|
||||
"afterMarkdowns": [
|
||||
"Und wieder, genau wie zuvor!"
|
||||
],
|
||||
"command": "git pull; git push",
|
||||
"beforeCommand": "git clone; git fakeTeamwork; git commit"
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "ModalAlert",
|
||||
"options": {
|
||||
"markdowns": [
|
||||
"Dieser Ablauf von `fetch`, `rebase` / `merge` und `push` ist sehr verbreitet. In zukünftigen Leveln werden wir uns kompliziertere Varianten dieses Workflows ansehen, aber jetzt probieren wir erst mal diesen aus.",
|
||||
"",
|
||||
"Um diesen Level zu lösen, gehe folgende Schritte durch:",
|
||||
"",
|
||||
"* Clone dein Repository",
|
||||
"* Simuliere einen entfernten Commit mit `git fakeTeamwork`",
|
||||
"* Erzeuge einen lokalen Commit",
|
||||
"* Benutze *Rebase*, um deine Arbeit schließlich pushen zu können"
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
};
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue