Condivisione di un codice tra due progetti in git

Question

Ho due progetti strettamente correlati (A e B) che condividono alcuni codice sorgente (S). Entrambi saranno rilasciati contemporaneamente e la versione rilasciata dovrebbe sempre utilizzare la stessa versione di codice condiviso. Il codice condiviso S verrà cambiato ragionevolmente spesso.

Quindi, apparirà a volte come questo:

• Una versione 1 utilizza la versione S 1
• B versione 1 utilizza la versione S 1
• Una versione 2 utilizza la versione S 2
• B versione 2 utilizza S versione 2

Qual è il modo migliore per gestirlo con git (e/o alcuni strumenti che utilizzano git)?

Qui sono le mie preoccupazioni:

• progetto A e progetto B dovrebbe essere in archivi separati (essi sono correlati, ma io non voglio avere libero flusso di codice tra loro)
• Se un codice condiviso aggiornato in un progetto, dovrebbe essere automaticamente aggiornato in un altro (non voglio avere una situazione in cui uno sviluppatore ha dimenticato di fare qualcosa e finisce per avere una versione obsoleta del codice condiviso).

Come ho capito una delle risposte canoniche è "utilizzare git submodule". Tuttavia, ho letto alcuni criticism su questo approccio. Mi sembrava che fosse più progettato per le librerie condivise che raramente cambiano.

Un altro approccio che ho letto è stato utilizzando git subtree

E ci sono un paio di approcci meno popolari: Repo, GitSlave

Quale sarebbe l'approccio migliore per gestire questo tipo di code sharing?

Answer 1

Una soluzione molto semplice sarebbe utilizzare tre repository: A, B e S. I repository di progetto A e B avrebbero un controllo nei loro Makefile per verificare che lo sviluppatore stia utilizzando l'ultimo codice inviato al repository, per esempio

check: 
     git fetch /path/to/S master:tip 
     git branch --contains tip | grep -q master 

La seconda riga avrà un valore di ritorno diverso da zero se lo sviluppatore ha una versione precedente del repository condiviso. Questo annullerà la compilazione con un errore. Lo sviluppatore può quindi andare e tirare manualmente il repository per procedere.

Invece di controllare il ramo master di S, è possibile controllare anche qualche altro ramo definito per essere sempre quello che gli sviluppatori dovrebbero utilizzare.