Nota: La mia domanda si concentra sul mio problema specifico (che coinvolge Liferay) ma spero possa essere utile a chiunque abbia bisogno di mantenere varie versioni di uno stesso progetto su git.

Lavoro in una società che scrive molti plugin per Liferay Portal . Questi plugin (portlet, temi, ecc.) Sono solitamente riutilizzabili e, naturalmente, dovrebbero essere aggiornati per le nuove versioni del portale.

Tuttavia, è normale migrare, diciamo, un portlet a una nuova versione di Liferay e per mantenere la sua versione precedente. Inoltre, spesso dobbiamo creare personalizzazioni molto specifiche per alcuni client, il che non ha senso essere aggiunto alla "versione principale".

Questi requisiti complicano il nostro lavoro ma, fortunatamente, possiamo assumere alcune semplificazioni. Ad esempio, i plugin vengono aggiornati di frequente da un solo programmatore alla volta. È molto raro che due o più funzioni vengano aggiunte a un plug-in contemporaneamente.

Ora stiamo migrando a Gitorious . Stiamo cercando di concepire un modello di ramificazione per tale scenario.

Il mio modello

Quello che ho proposto è stato:

1. Ogni plugin avrebbe il proprio repository in Gitorious all'interno di un progetto. Ad esempio, un portlet per la visualizzazione di gattini avrebbe un repository kittens-portlet all'interno del progetto liferay-portlets .
2. Quando crei un nuovo plug-in, crealo in un ramo chiamato in base alla versione di Liferay (ad esempio, lf5.2 ).
3. Ogni volta che viene eseguito un aggiornamento sul plug-in, l'aggiornamento viene approvato e distribuito in produzione, taggalo con una versione (ad esempio lf5.2v1 , lf5.2v2 ecc.) *
4. Ogni volta che un plugin deve essere portato su una nuova versione di Liferay, si dirama la versione più recente (creando, per esempio, il ramo lf6.0 ).
5. Una volta in produzione, il capo del nuovo ramo riceverà un tag come lf6.0v1 .
6. Ogni volta che dobbiamo personalizzare un plug-in in modo specifico per il cliente, creiamo un ramo con il nome del client (ad esempio, creiamo un ramo lf5.2clientcorp per il nostro client "ClientCorp Inc.")

Questo è un modello insolito: non avrebbe master e molti rami che non si uniscono. Ecco come suppongo che un repository con tale modello assomigli a:

Unamicohatrovatoquestosistemapiuttostocomplessoesoggettoaerrori.Hasuggeritol'eccellenteepopolare modello Vincent Driessen , che ho trovato ancora più difficile da gestire e disciplinare -demander. È fantastico (e testato!), Ma sembra troppo complesso per la nostra situazione.

Il modello del mio amico

Poi ha suggerito un altro modello: avremmo un repository per ciascun plugin in una versione di Liferay (quindi avremmo iniziato a creare un kittens-lf5.2-portlet e poi un kittens-lf6.0-portlet ), ognuno con un ramo master e un develop branch. Il master sarebbe sempre pronto per la distribuzione. (Oppure potrebbe essere il contrario, master e stable , come suggerito da Steve Losh ).

Questo è molto semplice, ma non mi piaceva questo sistema:

1. potrebbe risultare in una quantità enorme di repository in un progetto, rendendo difficile la navigazione di Gitorious.
2. Il nome della directory del progetto è pertinente. Se qualcuno clona il repository su una kittens-lf6.0-portlet dir e genera il WAR con ant (come al solito), anche il nome WAR sarà kittens-lf6.0-portlet . Le versioni precedenti di questo portlet (denominate kittens-portlet ad esempio) sarebbero considerate portlet diversi (e probabilmente mancanti) in un portale aggiornato. Un po 'di attenzione può evitarlo ma preferirei evitarlo.
3. Le diverse versioni dello stesso plugin sarebbero mantenute separate. Mi spezzo il cuore: (
4. kittens-lf6.0-portlet è un brutto nome per un repository, penso.

Sospetto che i due ultimi punti, che sono anche i due più soggettivi, siano la ragione principale della mia mancanza di volontà. Tuttavia, tutte e quattro le obiezioni stanno.

OTOH, la mia proposta mi sembra strana e mi chiedo se ci siano bug nascosti su di essa. OT3rdH git è così potente e flessibile che penso che non dovrei provare vergogna nell'esplorare le sue possibilità.

Quindi, chiedo:

1. Quale sarebbe il miglior modello? La mia proposta? La modella del mio amico? L'ormai tradizionale sistema Vincent Driessen?
2. Quale altro modello di ramificazione suggeriresti?
3. Se pensi che la mia modella sia cattiva, perché la pensi così? Mi piacerebbe sapere quali sono gli svantaggi e i punti ciechi.

* In realtà, preferirei taggare il commit con una versione come v1 ma a quanto pare un tag in git non ha scope nel ramo - cioè, non potrei avere un tag dell'1 v1 in lf5.2 e un altro in lf6.0 - quindi devo nominare il ramo. È corretto BTW?