Git-Workflow zum Aufbewahren von benutzerdefinierten Open-Source-Software auf dem neuesten Stand?

Question

Unsere Universität bietet Web -Hosting für Campus -Abteilungen auf Servern, die wir verwalten. Die Installation von Open-Source-Programmen von Drittanbietern erfordert die Änderung von Dateiberechtigungen und Code im Programm, bevor es ausgeführt wird. (Wir verwenden Suexec, wenn Sie vertraut sind.)

Derzeit bieten wir WordPress über ein Installationsproskript an. Der Benutzer lädt die neueste stabile Version hoch und führt ein serverseitiges PHP-Skript über SSH aus. Dieses PHP -Skript modifiziert die Dateiberechtigungen aller Dateien/Ordner. Fügt einen Code in verschiedenen Dateien hinzu und erstellt einige neue Dateien. Dieses Installationskript ist ein umständlicher Balanceakt, wenn eine neue stabile Version veröffentlicht wird.

Ich möchte anfangen, die Versionskontrolle (speziell GIT) zu verwenden, um unsere benutzerdefinierten Änderungen zu verfolgen, anstatt sich auf ein Skript zu verlassen, um die Änderungen vorzunehmen, bin mir jedoch nicht sicher, ob der Workflow verwendet wird. Ich bin mit Verzweigungen und Verschmelzung vertraut, aber ich bin mir nicht sicher, wie wir unsere alten Änderungen integrieren sollen, wenn eine neue Veröffentlichung ausgestellt wird.

Was sollte mein Git -Workflow sein, um die neuen Änderungen aus dem WordPress -Kern zu integrieren, aber auch unsere älteren kundenspezifischen Änderungen zu bewahren?

Answer 1

Ich würde vorschlagen, Ihre Änderungen in einer Niederlassung zu behalten und diese Zweigstelle von WordPress gegen die neuesten zu reservieren, wenn Sie aktualisieren. In einer groben Zeitleiste ...

              +-- WordPress 1.0
              v
[master] --*--*
               \
[custom]        *--*--*     <- your customizations

Wenn Sie WordPress aktualisieren möchten, wechseln Sie zu Master und machen Sie mit dem neuesten Souce einen neuen Commit ein (oder verwenden Sie GIT-SVN, um den Master synchron zu halten):

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
               \
[custom]        *--*--*     <- your customizations

Jetzt können Sie eine machen git rebase master custom Um Ihre Änderungen gegen die neuesten nachzubilden und Konflikte auf dem Weg zu lösen. Ihre Zeitleiste würde dann so aussehen:

              +-- WordPress 1.0
              |     +-- WordPress 1.1
              v     v
[master] --*--*--*--* 
                     \
[custom]              *--*--*     <- your customizations

Aktualisieren: Um ein bisschen Begründung zu liefern ... mag ich diesen Ansatz für dieses Problem, da er eine klare Unterscheidung zwischen Code von WordPress und Ihren Anpassungen bietet. Wenn Sie eine neue Version von WordPress erhalten, interessieren Sie sich wirklich nicht für "Integration". Sie möchten Ihre Anpassungen wieder auf die neue Version von WordPress anwenden. Meiner Ansicht nach ist diese Rekustomisierung am einfachsten durch eine Rebase zu begehen. Bei Konflikten ist wahrscheinlich eine Anpassung gesprungen, sodass das alte Anpassungsbefehl sowieso Müll ist - besser, das Problem in seiner Quelle zu beheben und die aktualisierte Geschichte sauber zu halten.

Nach master wird aktualisiert und custom Die Mitarbeiter wurden wiederhergestellt und weitergegeben.

Dies ist nur meine Meinung, wie ein fester Rebase> Fusion -Befürworter. Die Schönheit von Git ist, dass es selten eine richtige Antwort gibt. Passen Sie einfach weiter an, bis Sie etwas finden, das für Sie funktioniert.

Answer 2

Mein allgemeiner Ansatz ist es, zwei Zweige zu haben, upstream und master. Erstellen Sie Ihr Repository (das Sie in der Start in den master Zweig), überprüfen Sie die neueste Kopie des von Ihnen verwendeten Upstream -Codes und erstellen Sie dann die upsteram Zweig mit git branch upstream. Erstellen Sie außerdem ein Tag, das angibt, welche Upstream -Version Sie importiert haben, wie z. git tag wordpress-1.0. Normalerweise verwende ich dafür leichte Tags (ohne Anmerkungen, nur einen Zeiger auf eine Revision).

[wordpress-1.0]               Key: [tag]
v                                  branch
* <- upstream                      * commit
^- master 

Jetzt, während du noch in der bist master Filiale, kopieren Sie Ihre Änderungen und überprüfen Sie diese. Sie haben jetzt zwei Zweige. upstream die die makellose stromaufwärts gelegene Quelle enthält und master Was Ihre Änderungen enthält, wobei die Geschichte zeigt, an welchen Änderungen Sie vorgenommen haben upstream.

[wordpress-1.0]
v
* <- upstream
 \
  +--* <- master 

Nehmen Sie alle Ihre Modifikationen in der master Zweig.

[wordpress-1.0]
v
* <- upstream
 \
  +--*--*--* <- master 

Wenn eine neue Version des Upstream -Codes kommt, lesen Sie Ihre upstream Zweig (git checkout upstream), alles außer dem räumen .git Verzeichnis und kopieren Sie in der neuen Upstream -Version. Verwenden git add -A Um alle Änderungen in der vorgelagerten Version zu inszenieren, begehen Sie sie und markieren Sie sie.

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--* <- upstream
 \
  +--*--*--* <- master 

Schauen Sie sich jetzt an master, und fusionieren Sie Ihre vorgelagerten Änderungen. Zu diesem Zeitpunkt können Sie wählen, wie Sie zusammenführen können, z. B. die neue Upstream -Version, die Einnahme Ihrer Version oder die Annahme von Veränderungen, genau wie Sie es in einer normalen Zusammenführung tun.

[wordpress-1.0]
|  [wordpress-1.1]
v  v
*--*--------+ <- upstream
 \           \
  +--*--*--*--* <- master 

Also passieren alle Ihre Änderungen auf master, und alle stromaufwärts gelegenen Versionen sind genau so begangen, wie es ist upstream. Auf diese Weise können Sie am einfachsten genau sehen, wie sich Ihr Code von der vorgelagerten Version unterscheidet. Er hilft, den Überblick zu behalten, welche Änderungen Sie bereits mit der vorgelagerten Version und so weiter zusammengefasst haben.

[wordpress-1.0]
|  [wordpress-1.1]
|  |           [wordpress-2.0]
v  v           v
*--*--------+--*-+ <- upstream
 \           \    \ 
  +--*--*--*--*----*--* <- master 

Ich hoffe, das hilft, lassen Sie mich wissen, wenn Sie weitere Fragen haben.