blob: 655c76d842f5c3f432df1eb1736bb87cb4dc080c [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001Typischer Arbeitsablauf
2=======================
3
4(Es gibt andere Arbeitsweisen, aber dies hier ist eine, die sich bewaehrt
5 hat.)
6
7Nehmen wir an, ich moechte etwas neues einbauen, einen Bug fixen etc.
8Alle der folgenden Schritt werden auf eurem eigenen Rechner in eurem lokalen
9Clone 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
15Zuerst einmal wird ein checkout des Zweiges 'master' gemacht. Und in diesen
16Zweig hol ich mir erstmal den aktuellen Stand aus dem Mud (pull).
17
18Jetzt moechte ich alle Aenderungen erstmal in einem separaten Zweig machen.
19Warum? Weil dann der 'master' (das ist der aktive Zweig im Mud!) immer in
20einem benutzbaren Zustand ist. Desweiteren kann man einen Zweig einfach
21wegwerfen, wenn irgendwas groesseres schiefgelaufen ist...
22Ausserdem ist es dann einfacher, zwischenzeitliche Aenderungen aus dem Mud zu
23integrieren.
24
25# Schritt 2: Neuen Zweig erstellen
26> git checkout -b neue_kampftaktik
27Hiermit wird ein neuer Zweig erstellt und gleichzeitig in ihn gewechselt.
28
29Hier mach ich jetzt alle moeglichen Arbeiten und Basteleien, die ich fuer die
30neue 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
42Hiermit lasse ich mir anzeigen, welche Dateien nicht-committete Aenderungen
43enthalten (oder neu sind/geloescht wurden).
44
45> git diff
46Dies zeigt mir alle nicht-committeten Aenderungen an - zeilenweise verglichen
47mit dem vorherigen Zustand.
48
49# Schritt 3.2: Aenderungen in lokales Repository commiten
50> git add <file> // einzelne Files auswaehlen
51ODER
52> git add -A ./ // alle Files auswaehlen
53Hiermit merke alle gemachten Aenderungen fuer den naechsten Commit vor.
54Ich koennte hier aber auch einzelne Dateien auswaehlen oder sogar nur
55bestimmte Teile der Aenderungen in einer Datei. (Hierzu bitte die
56Git-Doku bemuehen.)
57
58> git commit
59Hiermit erstelle ich einen Commit, der die bisherigen Aenderungen umfasst.
60Dabei wird ein Editor geoeffnet, in den ich eine informative Nachricht ueber
61meine Aenderungen hinterlassen kann. Das ist besonders wichtig, wenn ich in
62fremden Gebieten arbeite, aber auch fuer mich und einen etwaigen abnehmenden
63Magier sehr sinnvoll.
64Anregung: Die erste Zeile ist das sog. Betreff des Commits - vergleichbar mit
65dem Betreff einer eMail. Anschliessend sollte eine leere Zeile folgen und
66danach eine laengere Beschreibung eingeben werden, sofern noetig/sinnvoll.
67
68Wenn ich an diesem Punkt mit dem Bugfix oder Feature noch nicht fertig bin:
69einfach die letzten 4 Befehle aus Schritt 3 beliebig oft wiederholen, d.h.
70beliebig viele weitere Commits machen.
71
72# Schritt 4: Aenderungen in lokalen Master-Zweig mergen
73Bin ich dann schliesslich aber mal fertig, gehe ich erstmal zurueck zum
74master-Zweig:
75
76> git checkout master
77Huch! Ploetzlich sind alle Dateien auf dem alten Stand! Keine Sorge,
78unsere Aenderungen sind im Zweig 'neue_kampftaktik' sicher verwahrt.
79
80Achtung: wenn ihr mit anderen zusammen arbeitet, koennte jemand
81anderes im MUD Aenderungen vorgenommen haben. Ein einfaches
82> git pull
83um die Dateien im 'master'-Zweig auf den neuesten Stand zu bringen,
84zeigt euch auch Aenderungen. Wenn da jetzt
85 'Already up-to-date.'
86steht, ist alles in Butter, ansonsten siehe unten bei 4.1.extra.
87
88> git merge neue_kampftaktik
89Mit 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
93Jetzt bin ich bereit, die Aenderungen ins Mud zu uebertragen:
94> git push
95Job done!
96Hier kommen jetzt div. Ausgaben vom Mud, die etwas ueber den Erfolg und
97Misserfolg des Pushes sagen. ;-)
98Wenn am Ende steht
99 'Your changes were copied to the mudlib.'
100ist alles erfolgreich.
101
102Steht 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!"
106ist an sich auch alles gut. Aber dann gab es im Mud eben doch noch
107Aenderungen, die es nicht im Git-Repo gab, die gemerged wurden. In diesem
108Fall sollte man den aktuellen Zustand sich nochmal holen:
109> git pull
110Und dann anschauen, dieser Merge auch das richtige gemacht hat:
111> git log -p
112Hiermit kriege ich eine schoene Liste aller Commits angezeigt und -p sorgt
113dafuer, dass dabei alle Aenderungen angezeigt werden, nicht nur die
114Commit-Nachricht.
115
116# Sonderfaelle und erweiterte Moeglichkeiten
117# Schritt 4.1.extra: Zwischenzeitliche Aenderungen im MUD beruecksichtigen
118
119Es koennte sein, dass man fuer den Branch ne ganze Weile gebraucht hat -
120und dass waehrend meiner Arbeit jemand anders Aenderungen (im Mud oder
121Repo) gemacht hat.
122
123Diese Aenderungen sollte man sich wie geschrieben als erstes nach dem
124Umschalten zum master-Zweig holen:
125> git pull
126
127Jetzt geh ich wieder in meinen Zweig (ohne -b)
128> git checkout neue_kampftaktik
129und mache ein sog. Rebase. Damit verschiebe ich sozusagen, den Punkt,
130an dem mein Zweig vom 'master' abzweigt und tue so, als ob die eben
131geholten 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
136Der Vorteil ist: wenn jetzt was kaputt gegangen ist, es also Konflikte gibt,
137dann gibt es die nur in meinem Zweig 'neue_kampftaktik' und dort kann ich
138sie in aller Ruhe reparieren. Sowohl der 'master' im MUD als auch mein
139lokaler 'master' sind intakt.
140
141Und jetzt geht es wie oben weiter.
142
143SIEHE 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
15102. Feb 2013 Gloinson