doc/wiz/git-workflow - mudlib-public - Gitiles

 Typischer Arbeitsablauf
 =======================

 (Es gibt andere Arbeitsweisen, aber dies hier ist eine, die sich bewaehrt
  hat.)

 Nehmen wir an, ich moechte etwas neues einbauen, einen Bug fixen etc.
 Alle der folgenden Schritt werden auf eurem eigenen Rechner in eurem lokalen
 Clone des jeweiligen Repositories durchgefuehrt.

 # Schritt 1: Repository clonen und/oder updaten
 > git clone git@mg.mud.de:/dings/bums
 > git checkout master
 > git pull
 Zuerst einmal wird ein checkout des Zweiges 'master' gemacht. Und in diesen
 Zweig hol ich mir erstmal den aktuellen Stand aus dem Mud (pull).

 Jetzt moechte ich alle Aenderungen erstmal in einem separaten Zweig machen.
 Warum? Weil dann der 'master' (das ist der aktive Zweig im Mud!) immer in
 einem benutzbaren Zustand ist. Desweiteren kann man einen Zweig einfach
 wegwerfen, wenn irgendwas groesseres schiefgelaufen ist...
 Ausserdem ist es dann einfacher, zwischenzeitliche Aenderungen aus dem Mud zu
 integrieren.

 # Schritt 2: Neuen Zweig erstellen
 > git checkout -b neue_kampftaktik
 Hiermit wird  ein neuer Zweig erstellt und gleichzeitig in ihn gewechselt.

 Hier mach ich jetzt alle moeglichen Arbeiten und Basteleien, die ich fuer die
 neue Kampftaktik brauche. Tipps dazu:
 * Viele und haeufige Commits machen! Je kleiner einzelne Commits sind, desto
   besser kann man Aenderungen spaeter verfolgen (was z.B. super ist, wenn
   jemand was abnehmen muss!) und desto besser kann man einzelne Aenderungen
   spaeter bei Bedarf auch rueckgaengig machen, wenn man merkt, dass man
   stellenweise Unsinn gebaut hat. ;-)
 * Thematisch unterschiedliche Dinge in verschiedene Commits packen. Also zB
   erst Syntaxfehler editieren und commiten, dann eine neue Methode fuer
   etwas ganz andere schreiben und commiten.

 # Schritt 3.1: Aenderungen pruefen
 > git status
 Hiermit lasse ich mir anzeigen, welche Dateien nicht-committete Aenderungen
 enthalten (oder neu sind/geloescht wurden).

 > git diff
 Dies zeigt mir alle nicht-committeten Aenderungen an - zeilenweise verglichen
 mit dem vorherigen Zustand.

 # Schritt 3.2: Aenderungen in lokales Repository commiten
 > git add <file>                    // einzelne Files auswaehlen
 ODER
 > git add -A ./                     // alle Files auswaehlen
 Hiermit merke alle gemachten Aenderungen fuer den naechsten Commit vor.
 Ich koennte hier aber auch einzelne Dateien auswaehlen oder sogar nur
 bestimmte Teile der Aenderungen in einer Datei. (Hierzu bitte die
 Git-Doku bemuehen.)

 > git commit
 Hiermit erstelle ich einen Commit, der die bisherigen Aenderungen umfasst.
 Dabei wird ein Editor geoeffnet, in den ich eine informative Nachricht ueber
 meine Aenderungen hinterlassen kann. Das ist besonders wichtig, wenn ich in
 fremden Gebieten arbeite, aber auch fuer mich und einen etwaigen abnehmenden
 Magier sehr sinnvoll.
 Anregung: Die erste Zeile ist das sog. Betreff des Commits - vergleichbar mit
 dem Betreff einer eMail. Anschliessend sollte eine leere Zeile folgen und
 danach eine laengere Beschreibung eingeben werden, sofern noetig/sinnvoll.

 Wenn ich an diesem Punkt mit dem Bugfix oder Feature noch nicht fertig bin:
 einfach die letzten 4 Befehle aus Schritt 3 beliebig oft wiederholen, d.h.
 beliebig viele weitere Commits machen.

 # Schritt 4: Aenderungen in lokalen Master-Zweig mergen
 Bin ich dann schliesslich aber mal fertig, gehe ich erstmal zurueck zum
 master-Zweig:

 > git checkout master
 Huch! Ploetzlich sind alle Dateien auf dem alten Stand! Keine Sorge,
 unsere Aenderungen sind im Zweig 'neue_kampftaktik' sicher verwahrt.

 Achtung: wenn ihr mit anderen zusammen arbeitet, koennte jemand
 anderes im MUD Aenderungen vorgenommen haben. Ein einfaches
 > git pull
 um die Dateien im 'master'-Zweig auf den neuesten Stand zu bringen,
 zeigt euch auch Aenderungen. Wenn da jetzt
   'Already up-to-date.'
 steht, ist alles in Butter, ansonsten siehe unten bei 4.1.extra.

 > git merge neue_kampftaktik
 Mit diesem Kommando hole ich nun alle Aenderungen aus meinem Zweig
 'neue_kampftaktik' in den Zweig 'master' (merge).

 # Schritt 5: Aenderungen in das MUD-Repository uebertragen
 Jetzt bin ich bereit, die Aenderungen ins Mud zu uebertragen:
 > git push
 Job done!
 Hier kommen jetzt div. Ausgaben vom Mud, die etwas ueber den Erfolg und
 Misserfolg des Pushes sagen. ;-)
 Wenn am Ende steht
   'Your changes were copied to the mudlib.'
 ist alles erfolgreich.

 Steht am Ende ein
   'Your changes were merged successfull with changes in the mudlib and the
    merged state was copied to the mudlib. Do not forget to pull the merge
    commit!"
 ist an sich auch alles gut. Aber dann gab es im Mud eben doch noch
 Aenderungen, die es nicht im Git-Repo gab, die gemerged wurden. In diesem
 Fall sollte man den aktuellen Zustand sich nochmal holen:
 > git pull
 Und dann anschauen, dieser Merge auch das richtige gemacht hat:
 > git log -p
 Hiermit kriege ich eine schoene Liste aller Commits angezeigt und -p sorgt
 dafuer, dass dabei alle Aenderungen angezeigt werden, nicht nur die
 Commit-Nachricht.

 # Sonderfaelle und erweiterte Moeglichkeiten
 # Schritt 4.1.extra: Zwischenzeitliche Aenderungen im MUD beruecksichtigen

 Es koennte sein, dass man fuer den Branch ne ganze Weile gebraucht hat -
 und dass waehrend meiner Arbeit jemand anders Aenderungen (im Mud oder
 Repo) gemacht hat.

 Diese Aenderungen sollte man sich wie geschrieben als erstes nach dem
 Umschalten zum master-Zweig holen:
 > git pull

 Jetzt geh ich wieder in meinen Zweig (ohne -b)
 > git checkout neue_kampftaktik
 und mache ein sog. Rebase. Damit verschiebe ich sozusagen, den Punkt,
 an dem mein Zweig vom 'master' abzweigt und tue so, als ob die eben
 geholten Aenderungen schon da gewesen waeren, als ich den Zweig erstellte.
 (Andere Sichtweise: ich nehme meine Zweig und setz ihn auf den aktuellen
  'master' dran.)
 > git rebase master

 Der Vorteil ist: wenn jetzt was kaputt gegangen ist, es also Konflikte gibt,
 dann gibt es die nur in meinem Zweig 'neue_kampftaktik' und dort kann ich
 sie in aller Ruhe reparieren. Sowohl der 'master' im MUD als auch mein
 lokaler 'master' sind intakt.

 Und jetzt geht es wie oben weiter.

 SIEHE AUCH
   git-repositories: Repository-Verwaltung im Mud
   git-howto: Wie git benutzt wird
   git-kooperation: Ein ueber git-workflow hinausgehendes Beispiel zur
                    Synchronisation bzw Kooperation mehrerer Magier/Rechner
   git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
   git-faq: haeufig gestellte Fragen/Probleme

 02. Feb 2013 Gloinson
	Typischer Arbeitsablauf
	=======================

	(Es gibt andere Arbeitsweisen, aber dies hier ist eine, die sich bewaehrt
	hat.)

	Nehmen wir an, ich moechte etwas neues einbauen, einen Bug fixen etc.
	Alle der folgenden Schritt werden auf eurem eigenen Rechner in eurem lokalen
	Clone des jeweiligen Repositories durchgefuehrt.

	# Schritt 1: Repository clonen und/oder updaten
	> git clone git@mg.mud.de:/dings/bums
	> git checkout master
	> git pull
	Zuerst einmal wird ein checkout des Zweiges 'master' gemacht. Und in diesen
	Zweig hol ich mir erstmal den aktuellen Stand aus dem Mud (pull).

	Jetzt moechte ich alle Aenderungen erstmal in einem separaten Zweig machen.
	Warum? Weil dann der 'master' (das ist der aktive Zweig im Mud!) immer in
	einem benutzbaren Zustand ist. Desweiteren kann man einen Zweig einfach
	wegwerfen, wenn irgendwas groesseres schiefgelaufen ist...
	Ausserdem ist es dann einfacher, zwischenzeitliche Aenderungen aus dem Mud zu
	integrieren.

	# Schritt 2: Neuen Zweig erstellen
	> git checkout -b neue_kampftaktik
	Hiermit wird ein neuer Zweig erstellt und gleichzeitig in ihn gewechselt.

	Hier mach ich jetzt alle moeglichen Arbeiten und Basteleien, die ich fuer die
	neue Kampftaktik brauche. Tipps dazu:
	* Viele und haeufige Commits machen! Je kleiner einzelne Commits sind, desto
	besser kann man Aenderungen spaeter verfolgen (was z.B. super ist, wenn
	jemand was abnehmen muss!) und desto besser kann man einzelne Aenderungen
	spaeter bei Bedarf auch rueckgaengig machen, wenn man merkt, dass man
	stellenweise Unsinn gebaut hat. ;-)
	* Thematisch unterschiedliche Dinge in verschiedene Commits packen. Also zB
	erst Syntaxfehler editieren und commiten, dann eine neue Methode fuer
	etwas ganz andere schreiben und commiten.

	# Schritt 3.1: Aenderungen pruefen
	> git status
	Hiermit lasse ich mir anzeigen, welche Dateien nicht-committete Aenderungen
	enthalten (oder neu sind/geloescht wurden).

	> git diff
	Dies zeigt mir alle nicht-committeten Aenderungen an - zeilenweise verglichen
	mit dem vorherigen Zustand.

	# Schritt 3.2: Aenderungen in lokales Repository commiten
	> git add <file> // einzelne Files auswaehlen
	ODER
	> git add -A ./ // alle Files auswaehlen
	Hiermit merke alle gemachten Aenderungen fuer den naechsten Commit vor.
	Ich koennte hier aber auch einzelne Dateien auswaehlen oder sogar nur
	bestimmte Teile der Aenderungen in einer Datei. (Hierzu bitte die
	Git-Doku bemuehen.)

	> git commit
	Hiermit erstelle ich einen Commit, der die bisherigen Aenderungen umfasst.
	Dabei wird ein Editor geoeffnet, in den ich eine informative Nachricht ueber
	meine Aenderungen hinterlassen kann. Das ist besonders wichtig, wenn ich in
	fremden Gebieten arbeite, aber auch fuer mich und einen etwaigen abnehmenden
	Magier sehr sinnvoll.
	Anregung: Die erste Zeile ist das sog. Betreff des Commits - vergleichbar mit
	dem Betreff einer eMail. Anschliessend sollte eine leere Zeile folgen und
	danach eine laengere Beschreibung eingeben werden, sofern noetig/sinnvoll.

	Wenn ich an diesem Punkt mit dem Bugfix oder Feature noch nicht fertig bin:
	einfach die letzten 4 Befehle aus Schritt 3 beliebig oft wiederholen, d.h.
	beliebig viele weitere Commits machen.

	# Schritt 4: Aenderungen in lokalen Master-Zweig mergen
	Bin ich dann schliesslich aber mal fertig, gehe ich erstmal zurueck zum
	master-Zweig:

	> git checkout master
	Huch! Ploetzlich sind alle Dateien auf dem alten Stand! Keine Sorge,
	unsere Aenderungen sind im Zweig 'neue_kampftaktik' sicher verwahrt.

	Achtung: wenn ihr mit anderen zusammen arbeitet, koennte jemand
	anderes im MUD Aenderungen vorgenommen haben. Ein einfaches
	> git pull
	um die Dateien im 'master'-Zweig auf den neuesten Stand zu bringen,
	zeigt euch auch Aenderungen. Wenn da jetzt
	'Already up-to-date.'
	steht, ist alles in Butter, ansonsten siehe unten bei 4.1.extra.

	> git merge neue_kampftaktik
	Mit diesem Kommando hole ich nun alle Aenderungen aus meinem Zweig
	'neue_kampftaktik' in den Zweig 'master' (merge).

	# Schritt 5: Aenderungen in das MUD-Repository uebertragen
	Jetzt bin ich bereit, die Aenderungen ins Mud zu uebertragen:
	> git push
	Job done!
	Hier kommen jetzt div. Ausgaben vom Mud, die etwas ueber den Erfolg und
	Misserfolg des Pushes sagen. ;-)
	Wenn am Ende steht
	'Your changes were copied to the mudlib.'
	ist alles erfolgreich.

	Steht am Ende ein
	'Your changes were merged successfull with changes in the mudlib and the
	merged state was copied to the mudlib. Do not forget to pull the merge
	commit!"
	ist an sich auch alles gut. Aber dann gab es im Mud eben doch noch
	Aenderungen, die es nicht im Git-Repo gab, die gemerged wurden. In diesem
	Fall sollte man den aktuellen Zustand sich nochmal holen:
	> git pull
	Und dann anschauen, dieser Merge auch das richtige gemacht hat:
	> git log -p
	Hiermit kriege ich eine schoene Liste aller Commits angezeigt und -p sorgt
	dafuer, dass dabei alle Aenderungen angezeigt werden, nicht nur die
	Commit-Nachricht.

	# Sonderfaelle und erweiterte Moeglichkeiten
	# Schritt 4.1.extra: Zwischenzeitliche Aenderungen im MUD beruecksichtigen

	Es koennte sein, dass man fuer den Branch ne ganze Weile gebraucht hat -
	und dass waehrend meiner Arbeit jemand anders Aenderungen (im Mud oder
	Repo) gemacht hat.

	Diese Aenderungen sollte man sich wie geschrieben als erstes nach dem
	Umschalten zum master-Zweig holen:
	> git pull

	Jetzt geh ich wieder in meinen Zweig (ohne -b)
	> git checkout neue_kampftaktik
	und mache ein sog. Rebase. Damit verschiebe ich sozusagen, den Punkt,
	an dem mein Zweig vom 'master' abzweigt und tue so, als ob die eben
	geholten Aenderungen schon da gewesen waeren, als ich den Zweig erstellte.
	(Andere Sichtweise: ich nehme meine Zweig und setz ihn auf den aktuellen
	'master' dran.)
	> git rebase master

	Der Vorteil ist: wenn jetzt was kaputt gegangen ist, es also Konflikte gibt,
	dann gibt es die nur in meinem Zweig 'neue_kampftaktik' und dort kann ich
	sie in aller Ruhe reparieren. Sowohl der 'master' im MUD als auch mein
	lokaler 'master' sind intakt.

	Und jetzt geht es wie oben weiter.

	SIEHE AUCH
	git-repositories: Repository-Verwaltung im Mud
	git-howto: Wie git benutzt wird
	git-kooperation: Ein ueber git-workflow hinausgehendes Beispiel zur
	Synchronisation bzw Kooperation mehrerer Magier/Rechner
	git-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
	git-faq: haeufig gestellte Fragen/Probleme

	02. Feb 2013 Gloinson