diff --git a/doc/wiz/git-workflow b/doc/wiz/git-workflow
new file mode 100644
index 0000000..655c76d
--- /dev/null
+++ b/doc/wiz/git-workflow
@@ -0,0 +1,151 @@
+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