Come strutturare i repository git per il progetto?


9

Sto lavorando a un modulo di sincronizzazione dei contenuti per Drupal. Esiste un modulo server, che si trova su un sito Web ed espone il contenuto tramite un servizio web. C'è anche un modulo client, che si trova su un sito diverso e recupera e importa il contenuto a intervalli regolari.

Il server viene creato su Drupal 6. Il client viene creato su Drupal 7. Sarà necessaria una versione Druapl 7 del server. E poi ci sarà bisogno di una versione Drupal 8 sia del client che del server una volta rilasciata l'anno prossimo.

Sono abbastanza nuovo per git e controllo del codice sorgente, quindi mi chiedevo quale sia il modo migliore per impostare i repository git? Sarebbe un caso di avere un repository separato per ogni istanza, cioè:

Drupal 6 server = 1 repository
Drupal 6 client = 1 repository
Drupal 7 server = 1 repository
Drupal 7 client = 1 repository
etc 

O avrebbe più senso avere un repository per il server e un altro per il client, quindi creare rami per ogni versione di Drupal?

Attualmente ho 2 repository: uno per il client e un altro per il server.

Risposte:


7

A meno che il progetto non sia davvero enorme, sceglierei un singolo repository con sottodirectory per server e client e creerei un ramo per ogni versione. Puoi comunque avere più copie del repository nel caso in cui desideri accedere a più versioni contemporaneamente.

Mantenendo più repository, renderebbe il trasferimento delle modifiche più difficile del necessario (rebase è più facile dell'applicazione delle patch). Nel caso (improbabile) non ci saranno modifiche da applicare a più versioni, non perderai ancora nulla ...

Inoltre, puoi sempre passare a più repository: basta clonare il repository e rimuovere i rami che non desideri. Fare il contrario è più difficile.

Vorrei fare più repository solo se il server e il client non condividono nulla o se il codice è davvero enorme.


Questo è il modo in cui vado perché Drupal memorizza diverse versioni come filiali. Avrei anche +1 ma ho bisogno di 15 ripetizioni!
littledynamo,

4

Ho visto e lavorato con tali variazioni. Tutto in una cartella con sottocartelle per server e client o un repository ciascuno. Preferisco il singolo repository per ogni parte principale del progetto.

In caso di grandi cambiamenti di versione, creerei semplicemente anche nuovi repository. Sicuramente non hanno rami diversi per loro. Mentre i rami sono potenti per l'implementazione di nuove funzionalità e forse un ramo di distribuzione permanente, evito sempre che troppi di essi funzionino in parallelo per lungo tempo. Dovrai sempre mantenerli (fai i rebase quando cambia il ramo master ecc.), Quindi mantieni la struttura di base il più semplice possibile. Avere un repository extra è (secondo la mia modesta opinione) meno doloroso di manipolare rami in diversi stati. Soprattutto se client e server non condividono molto codice.

Non so molto su Drupal e quanto siano forti le differenze tra le versioni. Quindi il mio punto di preferire repository diversi si basa più sulla mia esperienza con Rails. Tra le versioni a volte ci sono grandi differenze in cose come il nome dei file o la struttura delle cartelle (ad esempio la pipeline di risorse) che rende più comodo creare un nuovo repository. Drupal (o qualsiasi altro framework) potrebbe avere meno differenze, quindi andrebbe bene continuare all'interno del repository esistente.


1
Grazie. È interessante perché ho appena scoperto che i moduli Drupal Core memorizzano versioni separate come rami. Penso che abbia senso imitare quella struttura. Vorrei +1 ma ho bisogno di 15 rappresentanti!
littledynamo,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.