Update auto-erzeugter Files
Change-Id: Ic0c03bce93b201a3bdffba41de9562947ad8ac8a
diff --git a/doc/efun-mg.index b/doc/efun-mg.index
index b963327..103deb9 100644
--- a/doc/efun-mg.index
+++ b/doc/efun-mg.index
@@ -4,9 +4,7 @@
Fuer einige efuns haben wir Ergaenzungen, Bemerkungen oder Beispiele
zu den Manpages aus dem Driver erstellt. Diese sind im Folgenden zu
-finden.
-
-Verzeichnis der dokumentierten sefuns im Morgengrauen:
+finden:
* add_action(E)
diff --git a/doc/lfun/AddDetail b/doc/lfun/AddDetail
index 951b48a..5236703 100644
--- a/doc/lfun/AddDetail
+++ b/doc/lfun/AddDetail
@@ -40,10 +40,13 @@
([0: "Defaulttext",
"rasse1": "r1text", ...]).
- Falls fuer die Rasse des das Detail untersuchenden Spielers ein
+ Die Rassenstrings muessen hierbei klein geschrieben werden, anders
+ als in P_RACE und P_REAL_RACE.
+
+ Falls fuer die Rasse des Spielers, der das Detail untersucht, ein
Eintrag im Mapping existiert, wird der entsprechende Text
zurueckgegeben, ansonsten der Defaulttext. Auf diese Weise sind
- rassenabhaengige Details moeglich. Siehe auch die Beispiele.
+ rassenabhaengige Details moeglich.
<desc> ist eine Closure.
In diesem Fall wird die Closure ausgefuehrt und das Ergebnis
zurueckgegeben. Die Closure bekommt dabei den Namen des Details
@@ -71,8 +74,8 @@
Ein rassenabhaengiges Detail:
AddDetail(({"bett","bettchen"}),
- ([0 :"Eine kleines Bett.\n", // Der Defaulttext
- "zwerg": // Die Rasse klein schreiben
+ ([0 :"Ein kleines Bett.\n", // Der Defaulttext
+ "zwerg": // Die Rasse klein schreiben
"Das Bett laedt geradezu zu einem Nickerchen ein.\n"]));
Und nun ein Detail mit Closure (diese Version ersetzt das Verhalten
@@ -107,4 +110,4 @@
Veraltet: AddSpecialDetail(), RemoveSpecialDetail(), P_READ_MSG
Sonstiges: GetDetail(), break_string()
-20.01.2015, Zesstra
+11.04.2020, Arathorn
diff --git a/doc/lfun/HasMiniQuest b/doc/lfun/HasMiniQuest
index c832f00..a557bee 100644
--- a/doc/lfun/HasMiniQuest
+++ b/doc/lfun/HasMiniQuest
@@ -47,7 +47,7 @@
========
if( QM->HasMiniQuest(getuid(this_player()), this_object())!=1 )
- write("Du bist noch nicht reif genug.\n");
+ tell_object(this_player(), "Du bist noch nicht reif genug.\n");
SIEHE AUCH
diff --git a/doc/wiz.index b/doc/wiz.index
index 8a68b6f..a8bd7ba 100644
--- a/doc/wiz.index
+++ b/doc/wiz.index
@@ -13,4 +13,8 @@
* Erstellung neuer Repositories in Gerrit
+* Upload via Gerrit
+
+* Git workflow
+
* Homemud
diff --git a/doc/wiz/gerrit-upload b/doc/wiz/gerrit-upload
new file mode 100644
index 0000000..c564777
--- /dev/null
+++ b/doc/wiz/gerrit-upload
@@ -0,0 +1,115 @@
+
+Upload via Gerrit
+*****************
+
+Zunaechst sei einmal auf die Manpage Git workflow verwiesen.
+
+
+Upload / Push ohne Review
+=========================
+
+Ihr folgt dem Git workflow einfach vollstaendig. Eure Aenderungen
+werden direkt in die aktive Mudlib uebertragen.
+
+
+Upload / Push mit Review
+========================
+
+Folgt dem Git workflow bis Schritt 4 (einschliesslich). Ab dort gehts
+wie folgt weiter:
+
+ 5. Pusht eure Aenderungen zum Review nach Gerrit: "git push
+ origin lokalerbranch:refs/for/master" Damit werden eure
+ Aenderungen des Zweigs lokalerbranch in den Review fuer den
+ master-Zweig im MG uebertragen. Fuer jeden Commit wird ein
+ Change in Gerrit erzeugt. Ihr bekommt in der Ausgabe auch die
+ URL zum Change, den ihr erzeugt habt. Anschliessend tragt ihr
+ entweder dort auf der Weboberflaeche einen oder mehrere Reviewer
+ ein oder redet mit denjenigen im Mud.
+
+ 6. Die Reviewerin hat oft Wuensche, d.h. ihr muesste den Change
+ nochmal ueberarbeiten. Dazu gibt es zwei Moeglichkeiten:
+
+ 1. Ihr aendert auf der Weboberflaeche selber ("Edit" und
+ spaeter dann "Publish Edit"
+
+ 2. Wollt ihr bei euch lokal auf dem Rechner nur einen (den
+ letzten Commit in eurem lokalen Zweig) aendern geht das am
+ besten mit "git commit --amend". Spaetestens nach dieser
+ Aenderungen **muss** in der Commit-Message die sog. Change-ID
+ aus Gerrit als *letzte Zeile* und mit einer Leerzeile
+ getrennt auftauchen, z.B. "Change-Id:
+ Ie8fe15834a0eb3917318dc291b97a28e34b85b75". Anschliessend
+ koennt ihr wie in Schritt 4. erneut pushen und der Change in
+ Gerrit wird aktualisiert.
+
+ 3. Wollt ihr mehrere Commits bei euch lokal auf dem Rechner
+ aendern, muesst in eurem lokalen Zweig ein sog. interaktives
+ rebase machen und in diesem dann eure Commits editieren.
+ Wechselt in euren lokalen Zweig und benutzt "git rebase -i
+ master" (dies bedeutet "setze diesen Zweig neu auf den master
+ auf und lass mich dabei Aenderungen vornehmen"). Spaetestens
+ hierbei **muss** in allen Commit-Messages die zu diesem
+ Commit passende Change-ID aus Gerrit als *letzte Zeile* und
+ mit einer Leerzeile getrennt auftauchen. Anschliessend koennt
+ ihr wie in Schritt 4. erneut pushen und alle Changes in
+ Gerrit werden aktualisiert.
+
+ 7. Wenn die Reviewerin zufrieden ist, wird sie den Change in den
+ Zweig 'master' mergen und er landet damit im MG.
+
+
+Weitere Infos
+=============
+
+Es gibt noch viele weitere Informationen, wie man Aenderungen in
+Gerrit bekommt (z.B. kann man direkt mit dem ersten Push automatisiert
+Reviewer fuer alle Changes festlegen, Topics und Hashtags zur
+Kategorisierung verwenden). Es ist empfehlenswert, in die Doku von
+Gerrit zu schauen:
+
+ * https://mg.mud.de/gerrit/Documentation/user-upload.html
+
+ * https://mg.mud.de/gerrit/Documentation/user-
+ upload.html#push_create
+
+ * https://mg.mud.de/gerrit/Documentation/user-
+ upload.html#push_replace
+
+Mehr Informationen ueber die Change-ID bekommt ihr hier:
+https://mg.mud.de/gerrit/Documentation/user-changeid.html
+
+Ihr koennt git auch beibringen, dass in alle eure Commit-Messages die
+sog. Change-ID automatisch ergaenzt wird, in dem ihr einen 'commit-
+msg' hook aus Gerrit in euerem Repository installiert: "scp -p -P
+29418 <user>@mg.mud.de:hooks/commit-msg .git/hooks/" Details bekommt
+ihr hier: https://mg.mud.de/gerrit/Documentation/user-
+changeid.html#creation
+
+Die Doku geht auch auf haeufige Taetigkeiten im Zusammenhang mit dem
+Upload von Aenderungen ein: https://mg.mud.de/gerrit/Documentation
+/user-changeid.html#_git_tasks
+
+
+Siehe auch
+==========
+
+ * gerrit
+
+ * Doku von Gerrit:
+
+ * https://mg.mud.de/gerrit/Documentation/intro-user.html
+
+ * https://mg.mud.de/gerrit/Documentation/index.html#_tutorials
+
+ * git-howto: Wie git benutzt wird
+
+ * git-workflow: Wie man sinnvoll vorgehen kann beim Entwickeln
+
+ * git-kooperation: Ein ueber git-workflow hinausgehendes Beispiel
+ zur Synchronisation bzw Kooperation mehrerer Magier/Rechner
+
+ * gerrit-sync: Wie die Synchronisierung zw. git-Repos und Mudlib
+ ablaeuft
+
+ * git-faq: haeufig gestellte Fragen/Probleme
diff --git a/doc/wiz/gerrit-workflow b/doc/wiz/gerrit-workflow
new file mode 100644
index 0000000..5b6ad88
--- /dev/null
+++ b/doc/wiz/gerrit-workflow
@@ -0,0 +1,176 @@
+
+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.
+
+1. Repository clonen und/oder updaten
+
+ 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.
+
+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 z.B. erst Syntaxfehler editieren und commiten,
+ dann eine neue Methode fuer etwas ganz andere schreiben und
+ commiten.
+
+3. Aenderungen pruefen und commiten
+
+ Hiermit lasse ich mir anzeigen, welche Dateien nicht-committete
+ Aenderungen enthalten (oder neu sind/geloescht wurden):
+
+ git status
+
+ Dies zeigt mir alle nicht-committeten Aenderungen an - zeilenweise
+ verglichen mit dem vorherigen Zustand:
+
+ git diff
+
+4. Aenderungen in lokales Repository commiten
+
+ Hiermit merke gemachten Aenderungen fuer den naechsten Commit vor.
+ Ich kann hier einzelne Dateien auswaehlen, bestimmte Dateien oder
+ sogar nur bestimmte Teile der Aenderungen in einer Datei. (Hierzu
+ bitte die Git-Doku bemuehen.):
+
+ git add <file> // einzelne Files auswaehlen
+ git add -A ./ // alle Files auswaehlen
+
+ 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. (bitte nur so
+ 50-60 Zeichen). Anschliessend muss eine leere Zeile folgen und
+ danach eine laengere Beschreibung eingeben werden:
+
+ git commit
+
+ Wenn ich an diesem Punkt mit dem Bugfix oder Feature noch nicht
+ fertig bin: einfach den Schritt 4 beliebig oft wiederholen, d.h.
+ beliebig viele weitere Commits machen.
+
+5. 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.
+
+ Mit diesem Kommando hole ich nun alle Aenderungen aus meinem Zweig
+ 'neue_kampftaktik' in den Zweig 'master' (merge):
+
+ git merge neue_kampftaktik
+
+6. Aenderungen in das MUD-Repository uebertragen
+
+ Jetzt bin ich bereit, die Aenderungen ins Mud zu uebertragen:
+
+ git push origin <lokaler_zweigname>:<zweigname_im_mg>
+
+ Job done! (Hinweis: nur der Branch "master" wird ins Mud selber
+ synchronisiert, alle
+
+ anderen Zweige existieren nur in den git-Repositories.)
+
+
+Sonderfaelle und erweiterte Moeglichkeiten
+==========================================
+
+1. 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
+==========
+
+ * gerrit
+
+ * Doku von Gerrit:
+
+ * *https://mg.mud.de/gerrit/Documentation/intro-user.html*
+
+ *
+ *https://mg.mud.de/gerrit/Documentation/index.html#_tutorials*
+
+ * git-howto: Wie git benutzt wird
+
+ * git-kooperation: Ein ueber git-workflow hinausgehendes Beispiel
+ zur Synchronisation bzw Kooperation mehrerer Magier/Rechner
+
+ * gerrit-sync: Wie die Synchronisierung zw. git-Repos und Mudlib
+ ablaeuft
+
+ * git-faq: haeufig gestellte Fragen/Probleme
diff --git a/doc/wiz/git-workflow b/doc/wiz/git-workflow
index 8433382..5018910 100644
--- a/doc/wiz/git-workflow
+++ b/doc/wiz/git-workflow
@@ -1,133 +1,182 @@
+
+Git workflow
+************
+
+
Typischer Arbeitsablauf
=======================
-(Es gibt andere Arbeitsweisen, aber dies hier ist eine, die sich bewaehrt
- hat.)
+(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.
+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 ssh://mgg/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).
+1. Repository clonen und/oder updaten:
-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.
+ git clone ssh://mgg/dings/bums
+ git checkout master
+ git pull
-# Schritt 2: Neuen Zweig erstellen
-> git checkout -b neue_kampftaktik
-Hiermit wird ein neuer Zweig erstellt und gleichzeitig in ihn gewechselt.
+ Zuerst einmal wird ein checkout des Zweiges 'master' gemacht. Und
+ in diesen Zweig hol ich mir erstmal den aktuellen Stand aus dem Mud
+ (pull).
-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.
+ 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 3.1: Aenderungen pruefen
-> git status
-Hiermit lasse ich mir anzeigen, welche Dateien nicht-committete Aenderungen
-enthalten (oder neu sind/geloescht wurden).
+2. Neuen Zweig erstellen:
-> git diff
-Dies zeigt mir alle nicht-committeten Aenderungen an - zeilenweise verglichen
-mit dem vorherigen Zustand.
+ git checkout -b neue_kampftaktik
-# 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.)
+ Hiermit wird ein neuer Zweig erstellt und gleichzeitig in ihn
+ gewechselt.
-> 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.
+ Hier mach ich jetzt alle moeglichen Arbeiten und Basteleien, die
+ ich fuer die neue Kampftaktik brauche. Tipps dazu:
-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.
+ * 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. ;-)
-# Schritt 4: Aenderungen in lokalen Master-Zweig mergen
-Bin ich dann schliesslich aber mal fertig, gehe ich erstmal zurueck zum
-master-Zweig:
+ * Thematisch unterschiedliche Dinge in verschiedene Commits
+ packen. Also z.B. erst Syntaxfehler editieren und commiten,
+ dann eine neue Methode fuer etwas ganz andere schreiben und
+ commiten.
-> git checkout master
-Huch! Ploetzlich sind alle Dateien auf dem alten Stand! Keine Sorge,
-unsere Aenderungen sind im Zweig 'neue_kampftaktik' sicher verwahrt.
+3. Aenderungen pruefen und commiten
-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.
+ Hiermit lasse ich mir anzeigen, welche Dateien nicht-committete
+ Aenderungen enthalten (oder neu sind/geloescht wurden):
-> git merge neue_kampftaktik
-Mit diesem Kommando hole ich nun alle Aenderungen aus meinem Zweig
-'neue_kampftaktik' in den Zweig 'master' (merge).
+ git status
-# Schritt 5: Aenderungen in das MUD-Repository uebertragen
-Jetzt bin ich bereit, die Aenderungen ins Mud zu uebertragen:
-> git push origin <lokaler_zweigname>:<zweigname_im_mg>
-Job done!
-(Hinweis: nur der Branch "master" wird ins Mud selber synchronisiert, alle
- anderen Zweige existieren nur in den git-Repositories.)
+ Dies zeigt mir alle nicht-committeten Aenderungen an - zeilenweise
+ verglichen mit dem vorherigen Zustand:
-# Sonderfaelle und erweiterte Moeglichkeiten
-# Schritt 4.1.extra: Zwischenzeitliche Aenderungen im MUD beruecksichtigen
+ git diff
-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.
+4. Aenderungen in lokales Repository commiten
-Diese Aenderungen sollte man sich wie geschrieben als erstes nach dem
-Umschalten zum master-Zweig holen:
-> git pull
+ Hiermit merke gemachten Aenderungen fuer den naechsten Commit vor.
+ Ich kann hier einzelne Dateien auswaehlen, bestimmte Dateien oder
+ sogar nur bestimmte Teile der Aenderungen in einer Datei. (Hierzu
+ bitte die Git-Doku bemuehen.):
-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
+ git add <file> // einzelne Files auswaehlen
+ git add -A ./ // alle Files auswaehlen
-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.
+ 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. (bitte nur so
+ 50-60 Zeichen). Anschliessend muss eine leere Zeile folgen und
+ danach eine laengere Beschreibung eingeben werden:
-Und jetzt geht es wie oben weiter.
+ git commit
+
+ Wenn ich an diesem Punkt mit dem Bugfix oder Feature noch nicht
+ fertig bin: einfach den Schritt 4 beliebig oft wiederholen, d.h.
+ beliebig viele weitere Commits machen.
+
+5. 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.
+
+ Mit diesem Kommando hole ich nun alle Aenderungen aus meinem Zweig
+ 'neue_kampftaktik' in den Zweig 'master' (merge):
+
+ git merge neue_kampftaktik
+
+6. Aenderungen in das MUD-Repository uebertragen Jetzt bin ich
+ bereit, die Aenderungen ins Mud zu uebertragen:
+
+ git push origin <lokaler_zweigname>:<zweigname_im_mg>
+
+ Job done! (Hinweis: nur der Branch "master" wird ins Mud selber
+ synchronisiert, alle anderen Zweige existieren nur in den git-
+ Repositories.)
+
+
+Sonderfaelle und erweiterte Moeglichkeiten
+==========================================
+
+1. 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
- gerrit
- git-howto: Wie git benutzt wird
- git-kooperation: Ein ueber git-workflow hinausgehendes Beispiel zur
- Synchronisation bzw Kooperation mehrerer Magier/Rechner
- gerrit-sync: Wie die Synchronisierung zw. git-Repos und Mudlib ablaeuft
- git-faq: haeufig gestellte Fragen/Probleme
+==========
+ * gerrit
+
+ * Doku von Gerrit:
+
+ * https://mg.mud.de/gerrit/Documentation/intro-user.html
+
+ * https://mg.mud.de/gerrit/Documentation/index.html#_tutorials
+
+ * *gerrit-upload*: Wie man Dinge in Gerrit hochlaedt
+
+ * git-howto: Wie git benutzt wird
+
+ * git-kooperation: Ein ueber git-workflow hinausgehendes Beispiel
+ zur Synchronisation bzw Kooperation mehrerer Magier/Rechner
+
+ * gerrit-sync: Wie die Synchronisierung zw. git-Repos und Mudlib
+ ablaeuft
+
+ * git-faq: haeufig gestellte Fragen/Probleme