github team workflow - a forcella o no?

Penso che la tua paura di forking provenga dalla fusione meno che stellare di SVN - perché non è la biforcazione a causare il problema - è la fusione.

Immergiti: scoprirai che è davvero fantastico! Non hai bisogno di over-fork (non forchetta per ogni modifica in ogni file), ma puoi biforcare per le funzionalità e unirle di nuovo.

Pensa a GitHub come a molte versioni che meritano di essere migliorate su molti concetti chiave nel controllo del codice sorgente.

Il concetto di una branca "stabile" e una forcella "sviluppo attivo" coprono molti di questi problemi, se sei titubante a biforcarsi. : 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 l'un l'altro con i diritti di commit, probabilmente troverai più semplice mantenere un singolo repository centrale a git e aggiungerti tutti come collaboratori a quel repository.

Di tanto in tanto facciamo ancora forchette private, ma in genere si tratta di modifiche esotiche o di test di una sola persona a cui in genere non interessa il resto, ma che desideriamo comunque archiviare in remoto.

Vorrei iniziare con un singolo repository centrale e lavorare solo con git per un po '. Forse la forcella privata crescerà su di te, forse no. O va bene.

In git, una fork è in realtà solo un altro ramo. Con il flusso di lavoro fork-for-each-each-developer, si impegna effettivamente che ogni sviluppatore abbia una filiale pubblica (remota) per tracciare le proprie modifiche allo sviluppo. Questo è utile per poter collaborare direttamente (peer-to-peer) tra gli sviluppatori. Dovrai unire le modifiche di ogni sviluppatore al repository centrale in ogni caso, quindi non penso che ci sia molto overhead aggiunto da questo.

Per un piccolo team di 2-3 sviluppatori è possibile utilizzare la ramificazione sul repository per gestire correzioni e funzionalità. Il problema è quando hai più sviluppatori e più funzioni e correzioni in fase di sviluppo.

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

Avrai anche problemi con la collaborazione in cui qualcuno sta forzando a spingere su un ramo condiviso che è sul 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 tracciare quali rami sono in corso di lavorazione e quali sono utili. Mantiene il pulitore di repo principale.

Tuttavia, la tua infrastruttura di test potrebbe fare affidamento sull'utilizzo del repository principale, quindi potrebbe essere più difficile testare le modifiche nel repository bifronte a meno che tu non abbia spinto il ramo verso l'upstream. Può essere difficile capire quando la ramificazione e la foratura sono le migliori, ma in generale, quando il team ha più di 4 persone e ci sono molte correzioni e funzioni, la forking è l'opzione migliore.