Come strutturare i repository git per il progetto?

Naviga le tue risposte
9

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

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

Sono abbastanza nuovo per git e controllo del codice sorgente, quindi mi chiedevo qual è il modo migliore per configurare i repository git? Sarebbe il 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.

    
posta littledynamo 13.11.2012 - 12:00
fonte

2 risposte

7

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

Mantenendo più repository, il trasferimento delle modifiche sarà più difficile del necessario (rebase è più semplice dell'applicazione di patch). Nel caso (improbabile) non ci saranno modifiche da applicare a più versioni, non si perde ancora nulla ...

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

Vado per più repository solo se il server e il client non condividono nulla o se il codice è veramente enorme.

    
risposta data 13.11.2012 - 12:49
fonte
4

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

In caso di modifiche alle versioni grandi, creerei 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 implementazione permanente, evito sempre di farne funzionare troppi parallelamente per un lungo periodo. Dovrai sempre mantenerli (fare rebases quando il ramo master è cambiato, ecc), quindi mantieni la struttura di base il più semplice possibile. Avere un repository extra è (a mio modesto parere) meno doloroso dei rami di giocoleria in diversi stati. Soprattutto se client e server non condividono molto codice.

Non so molto di 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 ci sono a volte grandi differenze in cose come il modo in cui i file sono denominati o la struttura delle cartelle (ad esempio la pipeline degli asset) che rende più comodo creare un nuovo repository. Drupal (o qualsiasi altro framework) può avere meno differenze, quindi sarebbe giusto andare avanti all'interno del repository esistente.

    
risposta data 13.11.2012 - 12:09
fonte

Leggi altre domande sui tag

Memorizzazione del carattere EOF (Fine del file) in un tipo di carattere Word per il superset di file e cartelle [chiuso]