MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | Typischer Arbeitsablauf |
| 2 | ======================= |
| 3 | |
| 4 | (Es gibt andere Arbeitsweisen, aber dies hier ist eine, die sich bewaehrt |
| 5 | hat.) |
| 6 | |
| 7 | Nehmen wir an, ich moechte etwas neues einbauen, einen Bug fixen etc. |
| 8 | Alle der folgenden Schritt werden auf eurem eigenen Rechner in eurem lokalen |
| 9 | Clone des jeweiligen Repositories durchgefuehrt. |
| 10 | |
| 11 | # Schritt 1: Repository clonen und/oder updaten |
| 12 | > git clone git@mg.mud.de:/dings/bums |
| 13 | > git checkout master |
| 14 | > git pull |
| 15 | Zuerst einmal wird ein checkout des Zweiges 'master' gemacht. Und in diesen |
| 16 | Zweig hol ich mir erstmal den aktuellen Stand aus dem Mud (pull). |
| 17 | |
| 18 | Jetzt moechte ich alle Aenderungen erstmal in einem separaten Zweig machen. |
| 19 | Warum? Weil dann der 'master' (das ist der aktive Zweig im Mud!) immer in |
| 20 | einem benutzbaren Zustand ist. Desweiteren kann man einen Zweig einfach |
| 21 | wegwerfen, wenn irgendwas groesseres schiefgelaufen ist... |
| 22 | Ausserdem ist es dann einfacher, zwischenzeitliche Aenderungen aus dem Mud zu |
| 23 | integrieren. |
| 24 | |
| 25 | # Schritt 2: Neuen Zweig erstellen |
| 26 | > git checkout -b neue_kampftaktik |
| 27 | Hiermit wird ein neuer Zweig erstellt und gleichzeitig in ihn gewechselt. |
| 28 | |
| 29 | Hier mach ich jetzt alle moeglichen Arbeiten und Basteleien, die ich fuer die |
| 30 | neue Kampftaktik brauche. Tipps dazu: |
| 31 | * Viele und haeufige Commits machen! Je kleiner einzelne Commits sind, desto |
| 32 | besser kann man Aenderungen spaeter verfolgen (was z.B. super ist, wenn |
| 33 | jemand was abnehmen muss!) und desto besser kann man einzelne Aenderungen |
| 34 | spaeter bei Bedarf auch rueckgaengig machen, wenn man merkt, dass man |
| 35 | stellenweise Unsinn gebaut hat. ;-) |
| 36 | * Thematisch unterschiedliche Dinge in verschiedene Commits packen. Also zB |
| 37 | erst Syntaxfehler editieren und commiten, dann eine neue Methode fuer |
| 38 | etwas ganz andere schreiben und commiten. |
| 39 | |
| 40 | # Schritt 3.1: Aenderungen pruefen |
| 41 | > git status |
| 42 | Hiermit lasse ich mir anzeigen, welche Dateien nicht-committete Aenderungen |
| 43 | enthalten (oder neu sind/geloescht wurden). |
| 44 | |
| 45 | > git diff |
| 46 | Dies zeigt mir alle nicht-committeten Aenderungen an - zeilenweise verglichen |
| 47 | mit dem vorherigen Zustand. |
| 48 | |
| 49 | # Schritt 3.2: Aenderungen in lokales Repository commiten |
| 50 | > git add <file> // einzelne Files auswaehlen |
| 51 | ODER |
| 52 | > git add -A ./ // alle Files auswaehlen |
| 53 | Hiermit merke alle gemachten Aenderungen fuer den naechsten Commit vor. |
| 54 | Ich koennte hier aber auch einzelne Dateien auswaehlen oder sogar nur |
| 55 | bestimmte Teile der Aenderungen in einer Datei. (Hierzu bitte die |
| 56 | Git-Doku bemuehen.) |
| 57 | |
| 58 | > git commit |
| 59 | Hiermit erstelle ich einen Commit, der die bisherigen Aenderungen umfasst. |
| 60 | Dabei wird ein Editor geoeffnet, in den ich eine informative Nachricht ueber |
| 61 | meine Aenderungen hinterlassen kann. Das ist besonders wichtig, wenn ich in |
| 62 | fremden Gebieten arbeite, aber auch fuer mich und einen etwaigen abnehmenden |
| 63 | Magier sehr sinnvoll. |
| 64 | Anregung: Die erste Zeile ist das sog. Betreff des Commits - vergleichbar mit |
| 65 | dem Betreff einer eMail. Anschliessend sollte eine leere Zeile folgen und |
| 66 | danach eine laengere Beschreibung eingeben werden, sofern noetig/sinnvoll. |
| 67 | |
| 68 | Wenn ich an diesem Punkt mit dem Bugfix oder Feature noch nicht fertig bin: |
| 69 | einfach die letzten 4 Befehle aus Schritt 3 beliebig oft wiederholen, d.h. |
| 70 | beliebig viele weitere Commits machen. |
| 71 | |
| 72 | # Schritt 4: Aenderungen in lokalen Master-Zweig mergen |
| 73 | Bin ich dann schliesslich aber mal fertig, gehe ich erstmal zurueck zum |
| 74 | master-Zweig: |
| 75 | |
| 76 | > git checkout master |
| 77 | Huch! Ploetzlich sind alle Dateien auf dem alten Stand! Keine Sorge, |
| 78 | unsere Aenderungen sind im Zweig 'neue_kampftaktik' sicher verwahrt. |
| 79 | |
| 80 | Achtung: wenn ihr mit anderen zusammen arbeitet, koennte jemand |
| 81 | anderes im MUD Aenderungen vorgenommen haben. Ein einfaches |
| 82 | > git pull |
| 83 | um die Dateien im 'master'-Zweig auf den neuesten Stand zu bringen, |
| 84 | zeigt euch auch Aenderungen. Wenn da jetzt |
| 85 | 'Already up-to-date.' |
| 86 | steht, ist alles in Butter, ansonsten siehe unten bei 4.1.extra. |
| 87 | |
| 88 | > git merge neue_kampftaktik |
| 89 | Mit diesem Kommando hole ich nun alle Aenderungen aus meinem Zweig |
| 90 | 'neue_kampftaktik' in den Zweig 'master' (merge). |
| 91 | |
| 92 | # Schritt 5: Aenderungen in das MUD-Repository uebertragen |
| 93 | Jetzt bin ich bereit, die Aenderungen ins Mud zu uebertragen: |
| 94 | > git push |
| 95 | Job done! |
| 96 | Hier kommen jetzt div. Ausgaben vom Mud, die etwas ueber den Erfolg und |
| 97 | Misserfolg des Pushes sagen. ;-) |
| 98 | Wenn am Ende steht |
| 99 | 'Your changes were copied to the mudlib.' |
| 100 | ist alles erfolgreich. |
| 101 | |
| 102 | Steht am Ende ein |
| 103 | 'Your changes were merged successfull with changes in the mudlib and the |
| 104 | merged state was copied to the mudlib. Do not forget to pull the merge |
| 105 | commit!" |
| 106 | ist an sich auch alles gut. Aber dann gab es im Mud eben doch noch |
| 107 | Aenderungen, die es nicht im Git-Repo gab, die gemerged wurden. In diesem |
| 108 | Fall sollte man den aktuellen Zustand sich nochmal holen: |
| 109 | > git pull |
| 110 | Und dann anschauen, dieser Merge auch das richtige gemacht hat: |
| 111 | > git log -p |
| 112 | Hiermit kriege ich eine schoene Liste aller Commits angezeigt und -p sorgt |
| 113 | dafuer, dass dabei alle Aenderungen angezeigt werden, nicht nur die |
| 114 | Commit-Nachricht. |
| 115 | |
| 116 | # Sonderfaelle und erweiterte Moeglichkeiten |
| 117 | # Schritt 4.1.extra: Zwischenzeitliche Aenderungen im MUD beruecksichtigen |
| 118 | |
| 119 | Es koennte sein, dass man fuer den Branch ne ganze Weile gebraucht hat - |
| 120 | und dass waehrend meiner Arbeit jemand anders Aenderungen (im Mud oder |
| 121 | Repo) gemacht hat. |
| 122 | |
| 123 | Diese Aenderungen sollte man sich wie geschrieben als erstes nach dem |
| 124 | Umschalten zum master-Zweig holen: |
| 125 | > git pull |
| 126 | |
| 127 | Jetzt geh ich wieder in meinen Zweig (ohne -b) |
| 128 | > git checkout neue_kampftaktik |
| 129 | und mache ein sog. Rebase. Damit verschiebe ich sozusagen, den Punkt, |
| 130 | an dem mein Zweig vom 'master' abzweigt und tue so, als ob die eben |
| 131 | geholten Aenderungen schon da gewesen waeren, als ich den Zweig erstellte. |
| 132 | (Andere Sichtweise: ich nehme meine Zweig und setz ihn auf den aktuellen |
| 133 | 'master' dran.) |
| 134 | > git rebase master |
| 135 | |
| 136 | Der Vorteil ist: wenn jetzt was kaputt gegangen ist, es also Konflikte gibt, |
| 137 | dann gibt es die nur in meinem Zweig 'neue_kampftaktik' und dort kann ich |
| 138 | sie in aller Ruhe reparieren. Sowohl der 'master' im MUD als auch mein |
| 139 | lokaler 'master' sind intakt. |
| 140 | |
| 141 | Und jetzt geht es wie oben weiter. |
| 142 | |
| 143 | SIEHE AUCH |
| 144 | git-repositories: Repository-Verwaltung im Mud |
| 145 | git-howto: Wie git benutzt wird |
| 146 | git-kooperation: Ein ueber git-workflow hinausgehendes Beispiel zur |
| 147 | Synchronisation bzw Kooperation mehrerer Magier/Rechner |
| 148 | git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft |
| 149 | git-faq: haeufig gestellte Fragen/Probleme |
| 150 | |
| 151 | 02. Feb 2013 Gloinson |