Trasferimento da SVN a GIT, unire le modifiche del flusso di lavoro da SVN a GIT con repository condivisi

Question

Giusto, quindi ho il compito di scoprire se GIT sarebbe una soluzione per un problema imminente che stiamo avendo. (Crea facilmente rami di funzionalità, rami di aggiornamento rapido, rami di bugfix, mantenendo pulito il bagagliaio e solo i problemi completati (funzionalità, hotfix, bugfix, ecc.) In modo che, una volta rilasciata una versione, non vengano rilasciati problemi parzialmente completati/impegnati

In precedenza utilizzavamo SVN, con una versione modificata del modello git-flow/branching qui descritto: http://nvie.com/img/git-model@2x.png Dove git-master è il nostro svn-trunk. Funziona-ish, ma è un po 'ingombrante con SVN . Soprattutto perché usiamo due repository condivisi.

e qui arriva il problema. In precedenza abbiamo utilizzato questi due repository condivise come gli esterni, e tutti i riferimenti esterni hanno indicato lib/a/branches/develop e lib/b/branches/develop. Questo era ingombrante per lavorare wi th se era necessaria una funzione/hotfix/bugfix branche perché richiedeva la creazione di tre rami, la modifica del super-progetto con i nuovi riferimenti e quindi l'accettazione di dette modifiche.

Dopo un po 'di attenzione, abbiamo deciso di utilizzare i rami dei repository della libreria. (quindi, superProject/lib/a è un ramo da lib/a/branches/develop) e gli aggiornamenti futuri (entrambi i modi) richiederebbero un'unione o da superProject/lib/a a lib/a/branches/develop o viceversa.

Questo tuttavia non risolveva ancora il nostro problema di commit completati a metà una volta che un rilascio sarebbe stato vicino. (E purtroppo, presso l'azienda in cui lavoro questo può essere necessario in un'ora). Così abbiamo pensato un po 'di più e abbiamo deciso di iniziare a provare ad usare gli strumenti forniti da Atlassian un po' di più, provando Bitbucket (in precedenza usando Crucible/FishEye) e usando il loro speciale flusso di lavoro integrato per git dove per ogni problema può essere un ramo creato e una volta completata una richiesta di pull può essere creata in modo che il nostro manager di rilascio controlli ciò che entra e ciò che non va nella prossima versione. Niente più problemi a metà cottura in /develop/ poiché tutti i problemi verranno eseguiti utilizzando detto flusso di lavoro.

Il problema che sto affrontando è come incorporare questi progetti condivisi (libreria aeb). Ho letto il web e ho trovato più siti che parlano di git-submodules, git-subtree-merging-strategy, git-subtree (lo script) e unione manuale (è lo stesso della fusione di sottostrutture?). Ma nessuno risponde veramente ad alcune delle mie domande sui principianti. Finora sono stato più incuriosito da git-subtree, ma il supporto della GUI sembra essere abissale. Né TortoiseGit, SourceTree ha un buon supporto per la GUI per la sottostruttura di git, che richiede azioni da riga di comando, e conoscendo la maggior parte dei colleghi, a loro non piace fare cose da linea di comando.

Che cosa mi ha anche stato dà fastidio è che non c'è nulla di buono, quello che posso trovare, informazioni sul da cui repository/ramo della git-sottostruttura è stato creato e il fatto che un clone dal repository git remoto non automaticamente includere i collegamenti remoti corretti per qualsiasi sottostruttura di git. Così se mi wan't nessuno dei miei colleghi sviluppatori per essere in grado di aggiornare il git-sottostruttura dalla loro remota origine avrebbero dovuto fare manualmente un git remote add -f libraryXXX http://repohere/lib-xxx.git (una volta) e poi fare git subtree pull --prefix locationGoesHere libraryXXX master (--squash optional)

Tutto questo sembra molto più ingombrante rispetto al flusso di lavoro per SVN con la fusione di rami avanti e indietro. Mi sto perdendo qualcosa? Sto leggendo informazioni obsolete? Sto solo non guardando il modo corretto di lavorare con i repository condivisi?

Alcune delle risorse che ho usato:

• https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
• https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt
• https://developer.atlassian.com/blog/2015/05/the-power-of-git-subtree/?continue=https%3A%2F%2Fdeveloper.atlassian.com%2Fblog%2F2015%2F05%2Fthe-power-of-git-subtree&application=dac
• https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec
• Git subtree -- sharing subtrees with contributors

Answer 1

E 'diffi culto per fare molte dichiarazioni sulla tua configurazione, anche con la descrizione dettagliata che hai dato. Tuttavia, posso dire che troverete la ramificazione in git per essere praticamente indolore (specialmente se paragonato a svn). Raccomando di utilizzare i sottomoduli per le dipendenze della libreria. Non sono perfetti, ma funzionano. Quando crei un ramo, quel ramo inizierà utilizzando la stessa versione delle librerie come genitore, e potrai modificare il file .gitmodules per utilizzarne di diversi. Devi ricordarti di creare un nuovo clone con il flag --recursive (o di usare git submodule update dopo la clonazione), ma è molto più semplice di quanto non lo sia per i sottoalberi.