Flusso di lavoro Git per mantenere aggiornato il software open source personalizzato?

Question

La nostra università fornisce hosting web ai dipartimenti del campus sui server che gestiamo. L'installazione di programmi di terze parti open source richiede la modifica delle autorizzazioni di file e il codice nel programma prima di eseguire. (Stiamo usando Suexec, se hai familiarità.)

Attualmente offriamo WordPress tramite uno script di installazione. L'utente carica la versione più recente e esegue uno script PHP lato server tramite SSH. Questo script PHP modifica le autorizzazioni di file di tutti i file/cartelle, Aggiunge/rimuove un po 'di codice in vari file e crea alcuni nuovi file. Questo script di installazione è un atto di bilanciamento ingombrante quando viene rilasciata una nuova versione stabile.

Voglio iniziare a utilizzare il controllo della versione (in particolare GIT) per tracciare le nostre modifiche personalizzate invece di fare affidamento su uno script per apportare le modifiche, ma non sono sicuro del flusso di lavoro da utilizzare. Ho familiarità con la ramificazione e la fusione, ma non sono sicuro di come integrare i nostri vecchi cambiamenti quando viene emessa una nuova versione.

Quale dovrebbe essere il mio flusso di lavoro Git per integrare i nuovi cambiamenti dal core di WordPress, ma anche preservare i nostri vecchi cambiamenti personalizzati?

Answer 1

Suggerirei di mantenere le tue modifiche in una filiale e di ribellarsi a quel ramo contro le ultime novità di WordPress ogni volta che si aggiorna. In una sequenza temporale approssimativa ...

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

Quando si desidera aggiornare WordPress, passa a Master e fai un nuovo impegno con l'ultimo souce (o usa Git-SVN per mantenere il padrone in sincronia):

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

Ora puoi fare un git rebase master custom Per riprodurre le modifiche contro le ultime novità, risolvendo eventuali conflitti lungo la strada. La tua sequenza temporale sarebbe quindi così:

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

Aggiornare: Per fornire un po 'di logica ... Mi piace questo approccio per questo problema perché fornisce una chiara differenziazione tra il codice da WordPress e le tue personalizzazioni. Quando ottieni una nuova versione di WordPress, non sei davvero interessato a "integrazione". Sei interessato a riapplicare le tue personalizzazioni alla nuova versione di WordPress. A mio avviso, quella ricustizzazione è più facilmente fatta commit da un rebase. Eventuali conflitti significano che una personalizzazione probabilmente si è rotta, quindi il vecchio commit di personalizzazione è comunque spazzatura - meglio risolvere il problema alla sua fonte e mantenere pulita la cronologia aggiornata.

Dopo master è aggiornato e custom Viene ribellato e spinto, i collaboratori avrebbero semplicemente riempito il loro lavoro in corso contro le ultime novità.

Questa è solo la mia opinione, come un sostenitore di una ferma rebase> unisci. La bellezza di Git è che raramente c'è una risposta giusta. Continua a adattarti finché non trovi qualcosa che funzioni per te.

Answer 2

Il mio approccio generale è avere due rami, upstream e master. Crea il tuo repository (che ti inizierà in master Branch), controlla l'ultima copia del codice a monte utilizzato, quindi crea il upsteram ramo con git branch upstream. Inoltre, crea un tag che indica quale versione a monte hai importato, come ad esempio git tag wordpress-1.0. Di solito uso tag leggeri per questo (quelli senza annotazioni, fondamentalmente un puntatore a una revisione).

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

Ora, mentre sei ancora in master ramo, copia le modifiche e controllano quelle. Ora hai due rami, upstream che contiene la fonte a monte incontaminata e master che contiene le tue modifiche, con la storia che mostra a quali modifiche hai apportato upstream.

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

Apportare tutte le tue modifiche in master ramo.

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

Quando arriva una nuova versione del codice a monte, dai un'occhiata al tuo upstream ramo (git checkout upstream), cancella tutto tranne il .git Directory e copia nella nuova versione a monte. Uso git add -A Per mettere in scena tutte le modifiche nella versione a monte, impegnarla e etichettarlo.

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

Ora, controlla master, e unisciti ai tuoi cambiamenti a monte. A questo punto, puoi scegliere come unire, come prendere la nuova versione a monte, prendere la tua versione o apportare modifiche unite, proprio come fai in una normale unione.

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

Quindi, tutti i tuoi cambiamenti si verificano master, e tutte le versioni a monte sono impegnate esattamente come lo è upstream. Ciò ti consentirà di vedere più facilmente come il tuo codice differisce dalla versione a monte, ti aiuterà a tenere traccia delle modifiche che hai già unito alla versione a monte e così via.

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

Spero che questo aiuti, fammi sapere se hai ulteriori domande.