Uso del flusso git con la sottostruttura git

Question

Ho appena effettuato la migrazione di un grande repository SVN a git e ho iniziato a utilizzare gitflow. Ha funzionato come un fascino, ma ora sto pensando di dividere quel grande repo in un numero di piccoli.

Diamo supposse l'albero delle directory pronti contro termine è la seguente:

/repo 
    - libs 
    - apps 
    -- app 1 
    -- app 2 

e vogliamo dividerlo in tre pronti contro termine, una con la struttura di base (libs e applicazioni directory) e le altre due con le directory apps .

Se uso git subtree per dividere in questo modo sarò in grado di utilizzare il flusso git singolarmente in ogni parte o dovrò usarlo globalmente?

PS: Questa è la mia prima domanda a StackOverflow, si prega di essere gentile :)

Answer 1

Non faccio uso flusso git, ma direi la risposta dipende da quanto si è modulare. È possibile implementare la struttura principale senza distribuire app1 e app2? È possibile distribuire app1 e app2 indipendentemente l'uno dall'altro? Il tuo team di sviluppo è sufficientemente grande e sofisticato da trattarli come flussi di lavoro indipendenti?

Se la risposta a queste domande è "sì", direi trattandole come progetti multipli, ciascuno con un flusso unico. Se la risposta a qualcuno di loro è "No", comunque, eviterei di fratturare il tuo progetto. Infatti, se le modifiche a app1 e app2 richiedono anche modifiche al repository principale il più delle volte, eviterei di fratturare i reposli.

I repository nidificati, siano essi eseguiti con sottostruttura, sottomoduli o (divinità proibita) solo per .gitignore, per definizione, rendono più complicati i flussi di lavoro. Comandi come git bisect e git log diventano solo un po 'meno utili; la cronologia e gli errori di tracciamento diventano solo un po 'più difficili. I nuovi sviluppatori devono imparare solo un po 'di più per iniziare a programmare. Dall'esperienza personale: percorri attentamente questo percorso. Se i tuoi sub-repos sono pesantemente intrecciati, tornerai qui tra un anno scrivendo questa risposta per qualcun altro che cerca di rompere il loro progetto, come una versione git problematica di Pay It Forward.