Entropia:MediaWiki-Update: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
(→Vorgehen am Beispiel des öffentlichen Wikis: db-update) |
||
| (5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Dieses Wiki hier (wie übrigens auch das [[intern-wiki]]) ist inzwischen über einen [http://www.mediawiki.org/wiki/Download_from_Git Git-Checkout] installiert. Das hat den Vorteil, dass es sehr einfach durch einen Branch-Merge upzudaten ist – und das sogar inkl. etwaiger kleinerer Code-Anpassungen, denn diese kann | |||
Git meist von selbst mergen. Letzteres ist sogar der Hauptgrund für diese Git-Methode: Bei einem Update über einen Tarball müsste man evt. Änderungen bei jedem Update manuell nachvollziehen (und vorher dokumentieren.) | |||
Das | == Vorgehen am Beispiel des öffentlichen Wikis == | ||
Eins befindet sich im Branch <code>entropia.de-wiki</code>: | |||
# git status | |||
# On branch entropia.de-wiki | |||
nothing to commit (working directory clean) | |||
Wenn eine neue Version releast wird (z.B. ein Security-Update), fetcht eins sich die Upstream-Änderungen: | |||
git fetch | |||
und mergt diese in den eigenen Branch (hier anhand des Tags <code>1.20.5</code>): | |||
git merge 1.20.5 | |||
=== DB-Update === | |||
Ggf. muss eins noch die DB updaten: | |||
php maintenance/update.php | |||
=== Diff gegen Upstream === | |||
Änderungen gegenüber Upstream sieht eins mit: | |||
git diff 1.20.5 | |||
Das bedeutet natürlich, dass Änderungen grundsätzlich nur im Branch <code>entropia.de-wiki</code> gepflegt & commited werden. | |||
== intern-wiki == | |||
Das intern-wiki wird genauso gepflegt, unser eigener Branch heisst allerdings dort <code>entropia.de-intern-wiki</code>. | |||
== Weblinks == | |||
* [http://www.mediawiki.org/wiki/Download_from_Git MediaWiki: Download from Git] | |||
Aktuelle Version vom 4. September 2013, 10:00 Uhr
Dieses Wiki hier (wie übrigens auch das intern-wiki) ist inzwischen über einen Git-Checkout installiert. Das hat den Vorteil, dass es sehr einfach durch einen Branch-Merge upzudaten ist – und das sogar inkl. etwaiger kleinerer Code-Anpassungen, denn diese kann Git meist von selbst mergen. Letzteres ist sogar der Hauptgrund für diese Git-Methode: Bei einem Update über einen Tarball müsste man evt. Änderungen bei jedem Update manuell nachvollziehen (und vorher dokumentieren.)
Vorgehen am Beispiel des öffentlichen Wikis
Eins befindet sich im Branch entropia.de-wiki:
# git status # On branch entropia.de-wiki nothing to commit (working directory clean)
Wenn eine neue Version releast wird (z.B. ein Security-Update), fetcht eins sich die Upstream-Änderungen:
git fetch
und mergt diese in den eigenen Branch (hier anhand des Tags 1.20.5):
git merge 1.20.5
DB-Update
Ggf. muss eins noch die DB updaten:
php maintenance/update.php
Diff gegen Upstream
Änderungen gegenüber Upstream sieht eins mit:
git diff 1.20.5
Das bedeutet natürlich, dass Änderungen grundsätzlich nur im Branch entropia.de-wiki gepflegt & commited werden.
intern-wiki
Das intern-wiki wird genauso gepflegt, unser eigener Branch heisst allerdings dort entropia.de-intern-wiki.