2012-04-20 17 views
5

Come suggeriresti di gestire la funzionalità specifica del client e di modificare le richieste entro Git-flow o Git in generale? Le funzionalità specifiche del client dovrebbero essere in un ramo separato dedicato al cliente? (Ogni client ha il proprio ramo dal ramo di sviluppo.) O dovrebbero essere in un repository separato? (Ogni client dispone di un repository dedicato, con il repository principale che è il nostro repository principale.)Funzionalità Git-Flow e client

+0

domanda interessante. Ma è un problema git-flow o solo un problema git? (Nota, sono nuovo sia per git che per git-flow, quindi non sono molto furbo.) –

+0

Beh, stiamo cercando di seguire la struttura git-flow, ma questo può essere applicato a Git in generale. Per esempio. quali sono le solite pratiche per gestire questi casi. – Dario

risposta

2

Vorrei creare un repository separato per la base e i client. I clienti avrebbero una base che avrebbe un ramo remoto, essendo la vostra base. Quando un cliente ha bisogno di una nuova versione è molto più semplice in questo modo. Se dovessi mettere tutti i client in un repository, dovresti modificare manualmente il ramo di integrazione/sviluppatore prima di avviare il rilascio di un flusso git. Ciò limiterebbe la tua capacità di lavorare su più versioni per diversi client.

4

Sembra che tu abbia un codice base che tutti i client utilizzano, e quindi hai alcuni "hack" per funzionalità specifiche del client.

A mio parere, si avrebbe tutto il codice "base" sul ramo principale. Tutti i client avrebbero un ramo specifico per il cliente. Fai attenzione e sai dove vengono apportate le modifiche.

Ogni tanto, assicurati di rebase i rami dei tuoi clienti, in pratica portandoli al codice base e poi riproducendo tutte le loro modifiche specifiche.

Il rebasing può essere abbastanza confuso finché non lo si vede in azione.

Utilizzo di numeri di commit sequenziali per chiarezza. I commit non sono numeri nella vita reale

 
Master is at commit 10 
\ 
    Branch has commits 10, 11, 12, 13, 14, 15 (notice it has commit 10 as well) 
| 
Master commits 16, 17 


When you rebase: 
    Master has 10, 16, 17. 
    Branch has 10, 16, 17, 11, 12, 13, 14, 15 

L'ordine qui è molto importante. Rebase riavvolge il ramo a 10, applica 16 e 17, quindi riproduce i suoi cambiamenti di 11, 12, 13, 14 e 15.

A questo punto, finché non ci sono conflitti, il ramo è fino a data con master AND ha le modifiche specifiche del cliente.