Esiste una strategia di ramo Git raccomandata per due prodotti nello stesso pronti contro termine?

4

Il mio team ha un repository Git per un ampio servizio che ha incorporato un micro-servizio correlato, ma abbastanza unico. Recentemente abbiamo deciso di separare il micro-servizio nel proprio servizio in termini di filiali di rilascio e implementazioni (in modo che possiamo implementare il micro-servizio indipendentemente dal grande servizio). Il gotcha è il codice comune condiviso tra il servizio di grandi dimensioni e il servizio micro, quindi il disaccoppiamento non è completo; di conseguenza, la proposta è di mantenere entrambi i servizi in una soluzione e in un unico pronti contro termine.

Per rispondere a questa domanda, supponiamo che non possiamo (o non lo faremo) spostare il micro servizio nel proprio repository. Esiste uno schema di ramificazione Git consigliato per avere due rilasci di diversi "prodotti" nello stesso repository?

Si noti che attualmente utilizziamo il modello di avere un ramo di sviluppo, quindi sono preoccupato che con ogni prodotto che ha il proprio ramo di rilascio, potremmo avere conflitti di fusione sgradevoli quando si ricongiungono in master e si sviluppano rami attraverso due versioni.

    
posta Craig 08.10.2018 - 04:21
fonte

2 risposte

7

La strategia raccomandata è "non farlo". Il modo più semplice per farlo con git è di avere tre repository:

  • Progetto A
  • Progetto B
  • Librerie comuni

Quindi utilizza git submodule (documentazione qui ) per sincronizzare entrambi i progetti A e B con il comune librerie (fondamentalmente il sottomodulo ti permette di avere un repository all'interno di un repository). Se utilizzi strumenti di generazione o di gestione delle dipendenze, come Maven, Gradle o npm, puoi saltare la parte git submodule e usarli per gestire la dipendenza (che è ancora più pulita e meno soggetta a errori).

Se non riesci a dividere il repository in tre, avrai bisogno di tre master separati con tre rami di sviluppo e rebase il master comune sui master dei due progetti per applicare le modifiche. Nota che è estremamente facile rompere qualcosa in questo modo (e finire con conflitti di unione), quindi questo richiederà estrema cura.

    
risposta data 08.10.2018 - 14:18
fonte
2

A un codice sorgente e un livello Git non c'è bisogno di una strategia di ramificazione separata. È necessario configurare la soluzione di build / deploy per poterne distribuire uno o entrambi, se necessario. Se vuoi fare una pausa netta e separare completamente questi due progetti, allora una strategia di ramificazione separata ha senso, altrimenti stai aggiungendo la complessità senza alcun guadagno. Dipende dal tuo flusso di lavoro e da chi sta facendo il lavoro, ma se lo stesso team gestirà entrambi i progetti e sono veramente correlati, tenerli negli stessi rami potrebbe essere una strategia migliore. Se vuoi davvero avere due diversi rami di rilascio, dovresti probabilmente averne tre; un ramo comune di rilascio che funge da punto di integrazione ed è il ramo di base per gli altri due rami.

    
risposta data 08.10.2018 - 14:27
fonte

Leggi altre domande sui tag