flusso di lavoro del team github - a fork o no?

Siamo un piccolo team di sviluppatori web che attualmente utilizza Subversion ma presto stiamo passando a Github.

Sto esaminando diversi tipi di flussi di lavoro di github e non siamo sicuri che l'intero concetto di fork in github per ogni sviluppatore sia una buona idea per noi.

Se utilizziamo le forcelle, capisco che ogni sviluppatore avrà i propri repository remoti e locali privati. Sono preoccupato che renderà difficile e troppo complesso spingere i changeset. Inoltre, la mia più grande preoccupazione è che costringerà ogni sviluppatore ad avere 2 telecomandi: origin (che è il fork remoto) e un upstream (che viene utilizzato per "sincronizzare" le modifiche dal repository principale). Non sono sicuro che sia un modo così semplice di fare le cose.

Questo è simile al flusso di lavoro spiegato qui: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

Se non utilizziamo le forcelle, possiamo probabilmente cavarcela usando un repository centrale creando un ramo per ogni attività su cui stiamo lavorando e unendoli nel ramo di sviluppo sullo stesso repository. Significa che non saremo in grado di limitare la fusione dei rami e potrebbe essere un po 'confuso avere molti rami nel repository centrale.

Qualche suggerimento da parte dei team che hanno provato entrambi i flussi di lavoro?

Penso che la tua paura di biforcarsi provenga dalla fusione meno che stellare - perché non è il biforcazione che causa il problema - è la fusione.

Tuffati - scoprirai che è davvero fantastico! Non è necessario eseguire il fork eccessivo (non eseguire il fork per ogni modifica in ogni file), ma è possibile eseguire il fork delle funzionalità e ricollegarsi.

Pensa a GitHub come a diverse versioni degne di essere migliorate su molti concetti chiave nel controllo del codice sorgente.

Il concetto di ramo "stabile" e di "fork di sviluppo attivo" coprono anche molti di questi problemi se esiti a fare biforcazione. : P

Abbiamo provato entrambi, con sviluppatori che sono molto a loro agio in svn. E se sei un gruppo di sviluppatori che già lavorano insieme e si fidano reciprocamente dei diritti di commit, probabilmente troverai più semplice mantenere un singolo repository centrale su Git e aggiungere tutti come collaboratori quel repository.

Occasionalmente facciamo ancora forcelle private, ma questo è in genere per modifiche esotiche o test per 1 persona a cui il resto non è in genere interessato, ma che desideriamo comunque conservare in remoto.

Vorrei iniziare con un singolo repository centrale e lavorare con Git per un po '. Forse il fork privato crescerà su di te, forse no. O va bene.

In effetti, una forchetta è davvero solo un altro ramo. Con il flusso di lavoro fork-for-each-developer, stai effettivamente imponendo che ogni sviluppatore disponga di un ramo pubblico (remoto) per tenere traccia dei cambiamenti di sviluppo. Ciò è utile per poter collaborare direttamente (peer-to-peer) tra sviluppatori. In ogni caso, dovrai unire le modifiche di ciascuno sviluppatore al repository centrale, quindi non credo che ci sia molto da aggiungere.

Per un piccolo team di 2-3 sviluppatori, è possibile utilizzare la diramazione sul repository per gestire correzioni e funzionalità. Il problema è quando hai più sviluppatori di così e più funzionalità e correzioni che sono in fase di sviluppo.

In tal caso, il tuo repository principale in Github avrà centinaia di filiali; alcuni saranno vecchi, dimenticati e non fusi.

Avrai anche problemi con la collaborazione in cui qualcuno sta spingendo forzatamente su un ramo condiviso che è nel repository. Ciò significa che nessuno può collaborare correttamente su quel ramo poiché una spinta forzata è una riscrittura della storia.

Il fork di un repository rende più facile tenere traccia di quali rami sono in corso di elaborazione e quali vanno bene. Mantiene più pulito il repository principale.

Tuttavia, l'infrastruttura di test potrebbe fare affidamento sull'utilizzo del repository principale, quindi potrebbe essere più difficile testare le modifiche nel repository a forcella a meno che non si sia spostato il ramo a monte. Può essere difficile capire quando le ramificazioni e il fork sono i migliori, ma in generale, quando il team ha più di 4 persone e ci sono molte correzioni e funzionalità, il fork è l'opzione migliore.