Domande sul flusso di lavoro per un team che utilizza un repository git-svn

Question

Ho letto su git e git-svn. Sono abbastanza nuovo da git, ma sono stato in grado di creare alcuni repository di base. Tuttavia, sono un po 'confuso su come il flusso di lavoro dovrebbe essere usato da un team per git-svn. L'obiettivo è di convertire svn in git per scopi di ramificazione e condivisione, quindi eseguire il commit al repository principale di svn quando è pronto per passare alla produzione. Ecco le mie domande:

Ogni membro del team dovrebbe creare un repository git dal repository svn? Questo approccio funzionerà quando si rimetterà nuovamente in svn/tirando gli uni dagli altri?

oppure

Se una git repo essere creato da svn, che poi pronti contro termine è spinto 'pubblicamente' per i membri del team per clonare? Quindi le modifiche verrebbero riportate al repository git originale per la ridefinizione e premendo su svn?

oppure

possiamo fare lo stesso come sopra, tranne basta tirare le modifiche da ogni altro repo copia di lavoro?

oppure

Am I di aggiungere troppa complessità per il flusso di lavoro e deve solo continuare ad usare svn, dato che non è un'opzione per convertire solo interamente a git?

Answer 1

Faccio qualcosa in questa direzione tutto il tempo.Qui, abbiamo un repository svn, ma molte persone preferiscono usare git. Abbiamo appena creato una persona come git respository, e poi l'abbiamo condivisa tra di noi (piuttosto che aver creato la propria copia git-svn - l'importazione originale ha richiesto più di 30 ore). Ora chiunque voglia vuole solo lavorare in git e git svn dcommit per trasferire le loro modifiche al repository svn "reale".

Answer 2

Git-svn supporta facilmente ciò che si desidera fare. Suggerirei che ogni sviluppatore crei il proprio repository Git dal repository Subversion (git svn clone). Gli sviluppatori possono tirarsi gli uni dagli altri, se lo desiderano, compresi i commit che sono già stati inseriti in Subversion e quelli che non lo hanno fatto.

L'equivalente git-svn di svn update è git svn rebase, che effettivamente fa un'operazione git rebase contro il repository Subversion. Eventuali commit che potresti essere pronti a commettere, che sono già stati commessi da qualcun altro, vengono saltati automaticamente.

Answer 3

Gli sviluppatori hanno mai avuto bisogno di un repository locale mentre non erano in grado di connettersi al repository principale? (es .: Coding su un aereo su un laptop)

Se no, allora eviterei del tutto questo mal di testa e basta usare SVN con rami specifici dello sviluppo.

Se, tuttavia, che ci piace molto l'approccio distribuito di git, vorrei andare con la vostra terza opzione:

Se uno repo git essere creato da svn, allora questo repo è spinto 'pubblicamente 'per i membri della squadra clonare? Quindi le modifiche verranno riportate a il repository git originale per la ridistribuzione e premendo su svn?

Con:

possiamo fare lo stesso come sopra, tranne basta tirare le modifiche da ogni altro lavorare copia repo?

Questo dovrebbe funzionare.

Answer 4

Pensate al repository git di ciascun utente come a un client di Subversion elegante, in particolare a quello con cui è facile condividere le revisioni senza coinvolgere il repository centrale. Quindi tutti dovrebbero fare ciò che sembra migliore e giusto per loro.

Si potrebbe anche pensare al repository Subversion come a un repository git fancy.

In caso di creazione di un repository git da svn, tale repository viene inserito "pubblicamente" per clonare i membri del team? Quindi le modifiche verrebbero riportate al repository git originale per la ridefinizione e premendo su svn?

Non credo che sia necessario, perché git svn clone funziona in gran parte lo stesso che git clone per cominciare.

La cosa più importante da fare è quello di sempre fare git svn rebase prima di fare git svn dcommit. Se stai facendo un sacco di condivisione delle revisioni tra repository git, è probabilmente una buona idea esaminare le modifiche che stai per inviare a Subversion prima di fare quello git svn dcommit.