Nota: la mia domanda è focalizzata sul mio problema specifico (che coinvolge Liferay) ma spero che possa essere utile per chiunque abbia bisogno di mantenere su git varie versioni di uno stesso progetto.

Lavoro in un'azienda che scrive molti plugin per Liferay Portal . Questi plugin (portlet, temi, ecc.) Sono generalmente riutilizzabili e, ovviamente, dovrebbero essere aggiornati per le nuove versioni del portale.

Tuttavia, è normale migrare, diciamo, un portlet a una nuova versione di Liferay e mantenere la 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 plug-in vengono aggiornati frequentemente da un solo programmatore alla volta. È molto raro che due o più funzioni vengano aggiunte contemporaneamente a un plug-in.

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

Il mio modello

Quello che ho proposto era:

1. Ogni plugin avrebbe il suo repository in Gitorious all'interno di un progetto. Ad esempio, un portlet per la visualizzazione di gattini avrebbe un kittens-portletrepository all'interno del liferay-portletsprogetto.
2. Quando si crea un nuovo plug-in, crearlo in una succursale denominata 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, contrassegnare il plug-in con una versione (ad esempio lf5.2v1, lf5.2v2ecc.) *
4. Ogni volta che un plugin deve essere portato su una nuova versione di Liferay, ramifichiamo la versione più recente (creando, ad esempio, il ramo lf6.0).
5. Una volta in produzione, il capo della nuova filiale riceverà un tag come lf6.0v1.
6. Ogni volta che dobbiamo personalizzare un plugin in un modo specifico per il cliente, creiamo una filiale con il nome del client (ad esempio, lf5.2clientcorpcreeremmo una filiale per il nostro client "ClientCorp Inc.")

Questo è un modello insolito: non avrebbe mastermolti rami che non si fondono. Questo è come suppongo che un repository con tale modello sarebbe simile a:

Un amico ha trovato questo sistema piuttosto complesso e soggetto a errori. Ha suggerito l'eccellente e popolare modello di Vincent Driessen , che ho trovato ancora più difficile da gestire e disciplinare. È ottimo (e testato!) Ovviamente ma sembra troppo complesso per la nostra situazione.

Il modello del mio amico

Quindi ha suggerito un altro modello: avremmo avuto un repository per ogni plugin in una versione di Liferay (quindi avremmo iniziato a creare a kittens-lf5.2-portlete poi a kittens-lf6.0-portlet), ognuno con un masterramo e un developramo. Il mastersarebbe sempre pronto per la distribuzione. (O potrebbe essere il contrario, mastere stable, come suggerito da Steve Losh ).

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

1. potrebbe comportare un sacco di repository in un progetto, rendendo difficile la navigazione di Gitorious.
2. Il nome della directory del progetto è rilevante. Se qualcuno clona il repository su una kittens-lf6.0-portletdirectory e genera la WAR con ant (come al solito), lo sarà anche il nome WAR kittens-lf6.0-portlet. Le vecchie versioni di questo portlet (chiamato kittens-portletad esempio) verrebbero considerate portlet diversi (e probabilmente mancanti) in un portale aggiornato. Un po 'di cura può evitarlo, ma preferirei evitarlo.
3. Le diverse versioni dello stesso plugin verrebbero mantenute separate. Mi spezzo il cuore :(
4. kittens-lf6.0-portlet è un brutto nome per un repository, credo.

Sospetto che gli ultimi due punti - che sono anche i due più soggettivi - siano la ragione principale della mia riluttanza. Tuttavia, tutte e quattro le obiezioni sono valide.

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

Quindi chiedo:

1. Quale sarebbe il modello migliore? 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 il mio modello sia cattivo, perché lo pensi? Mi piacerebbe imparare quali sono gli svantaggi e i punti ciechi.

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

Se leggo questo correttamente, i rami sono fondamentalmente una deviazione di un colpo dalla linea principale di sviluppo, non intendo mai essere ricollegati alla linea principale e i progressi nella linea principale non vengono mai applicati a questi rami. L'unica deviazione sarebbe che le correzioni di bug appropriate alla versione su cui si basava il ramo dovevano essere applicate al ramo.

La risposta ora ruota sul flusso di lavoro quotidiano, il numero di sviluppatori che lavorano su un ramo o il numero di modifiche sono aringhe rosse. Vedo il tuo bisogno principale di voler sapere quali rami ottengono un aggiornamento della correzione di bug da una modifica del ramo principale e per questo penso che il repository combinato con i rami sarà più efficiente poiché è tutto in un unico posto. Non c'è mai stata alcuna necessità di impollinazione incrociata, quindi repository separati lo imporrebbero, ma quello scenario non corrisponde alla realtà del tuo progetto come lo capisco.

Il modello Driessen funzionerebbe bene se il tuo progetto avesse bisogno di unire i rami nella linea principale di sviluppo, ma non ne hai bisogno. Anche così penso che ci sia merito nel mantenere un concetto InDevelopment e StableRelease se stai lavorando su un prodotto che è attivo.

Quindi per riassumere penso che il tuo progetto funzionerebbe bene con il tuo modello di diramazione più un trattino di Driessen per la tua linea principale. Il tuo chilometraggio può variare; Ho sempre lavorato con un ramo "in attesa di rilascio" che si trasforma in un ramo "in diretta" e un "rilascio successivo" separato che richiedono tutti l'impollinazione incrociata di correzioni e modifiche in vari punti, quindi la mia percezione potrebbe essere distorta.

Ciò che mi sorprende è il fatto che ogni portlet ha il proprio repository (ma la tua storia potrebbe non essere completa). Personalmente vorrei creare un repository per progetto. I progetti hanno spesso più portlet e sono tutti compilati nella stessa esecuzione rispetto alla stessa versione di Liferay. Ogni progetto può essere un duplicato di un progetto esistente che si basa su una versione diversa di Liferay ma dividerei un prodotto solo se le differenze sono troppo grandi. Se una build funziona con Liferay 5.1 e 5.2 non dividerei il progetto. Userei lo scripting o Maven (o entrambi) per far funzionare tutto. Vorrei utilizzare un Wiki (o Trello) per la gestione di ciascun prodotto e con quale versione di Liferay può essere costruita.

A proposito: sono un programmatore Java, specialista Maven, specialista Build e ho esperienza con Liferay e altri server portale (IBM WebSphere e Glassfish).

Ma questo è solo il mio € 0,02.