git workflow per mantenere aggiornato il software open source modificato dall'utente?

Question

La nostra università offre servizi di web hosting ai dipartimenti universitari sui server che gestiamo. L'installazione di programmi di terze parti open-source richiede la modifica delle autorizzazioni e del codice dei file nel programma prima che venga eseguito. (Stiamo usando suEXEC, se hai familiarità.)

Attualmente offriamo WordPress tramite uno script di installazione. L'utente carica la nuova versione stabile e esegue uno script PHP sul lato server tramite SSH. Questo script PHP modifica i permessi dei file di tutti i file/cartelle, aggiunge/rimuove alcuni codici in vari file e crea alcuni nuovi file. Questo script di installazione è un atto di bilanciamento ingombrante quando viene rilasciata una nuova versione stabile.

Desidero iniziare a utilizzare il controllo della versione (in particolare git) per tenere traccia delle modifiche personalizzate anziché affidarsi a uno script per apportare le modifiche, ma non sono sicuro del flusso di lavoro da utilizzare. Conosco la ramificazione e la fusione, ma non sono sicuro di come integrare le nostre vecchie modifiche quando viene rilasciata una nuova versione.

Quale dovrebbe essere il mio flusso di lavoro git per integrare le nuove modifiche dal core di WordPress, ma anche preservare le nostre modifiche personalizzate precedenti?

Answer 1

Suggerirei di mantenere le modifiche in un ramo e di ribasare quel ramo con le ultime da WordPress ogni volta che si aggiorna. In una timeline di massima ...

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

Quando si desidera aggiornare WordPress, passare da padroneggiare e fare un nuovo commit con l'ultima souce (o utilizzare git-svn per tenere master in sync):

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

Ora è possibile eseguire un git rebase master custom per riprodurre le modifiche rispetto all'ultima, risolvendo eventuali conflitti lungo il percorso. La vostra timeline sarebbe quindi simile a questa:

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

Aggiornamento: 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 personalizzazioni. Quando ottieni una nuova versione di WordPress, non sei davvero interessato a "integrazione". Ti interessa riapplicare le tue personalizzazioni alla nuova versione di WordPress. Dal mio punto di vista, la ri-personalizzazione è più facilmente commessa da commit attraverso un rebase. Qualsiasi conflitto significa che probabilmente si è rotta una personalizzazione, quindi il vecchio commit di personalizzazione è spazzatura comunque - meglio correggere il problema all'origine e mantenere pulita la cronologia aggiornata.

Dopo master viene aggiornato e custom viene rebased e spinto, i collaboratori semplicemente ribattere il loro work-in-progress contro il più recente.

Questa è solo la mia opinione, come una ditta rebase> unire il proponente. La bellezza di Git è che raramente c'è una risposta giusta. Continua a regolarti finché non trovi qualcosa che funzioni per te.

Answer 2

Il mio approccio generale è quello di avere due rami, upstream e master. Creare il repository (che inizierà nel ramo master), archiviare l'ultima copia del codice a monte che si utilizza e quindi creare il ramo upsteram con git branch upstream. Inoltre, crea un tag che indica quale versione a monte hai importato, 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 siete ancora nel ramo master, copiare le modifiche in e il check quelle. Ora avete due rami, upstream che contiene la sorgente a monte incontaminato e master che contiene le modifiche, con cronologia che mostra quali modifiche sono state apportate a upstream.

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

fare tutte le modifiche nel ramo master.

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

Quando una nuova versione del codice a monte arriva, controlla il tuo upstream ramo (git checkout upstream), cancellare tutto, ma la directory .git, e copiare nella nuova versione upstream. Utilizzare git add -A per mettere in scena tutte le modifiche nella versione upstream, eseguirne il commit e taggarla.

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

Ora, controlla master e unisci le modifiche originali. A questo punto, puoi scegliere come unire, come prendere la nuova versione upstream, prendere la tua versione, o prendere le modifiche unite, proprio come fai in una normale unione.

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

Quindi, tutte le modifiche accadere su master, e tutte le versioni upstream sono impegnati esattamente come è quello di upstream. Ciò ti permetterà di vedere con estrema facilità esattamente come il tuo codice differisce dalla versione upstream, ti aiuterà a tenere traccia delle modifiche che hai già combinato con la versione upstream e così via.

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

Spero che questo aiuti, fatemi sapere se avete ulteriori domande.