Repository, problemi, sviluppatori multipli e fork di Github Organization - Best Practices Workflow

Un titolo strano, sì, ma ho un po 'di terreno da percorrere, credo.

Abbiamo un account dell'organizzazione su github con repository privati. Vogliamo usare i problemi nativi di github / funzionalità pull-request (le richieste pull sono fondamentalmente esattamente ciò che vogliamo per quanto riguarda le revisioni del codice e le discussioni sulle funzionalità). Abbiamo trovato l' hub degli strumenti di defunkt che ha una piccola caratteristica interessante di essere in grado di convertire un problema esistente in una richiesta pull e associare automaticamente il tuo ramo corrente con esso.

Mi chiedo se sia meglio che ogni sviluppatore dell'organizzazione biforchi il repository dell'organizzazione per far funzionare le loro funzioni / correzioni di errori / ecc. Questo sembra un flusso di lavoro piuttosto solido (come, in pratica, è quello che fa ogni progetto open source su github) ma vogliamo essere sicuri di poter tracciare i problemi ed estrarre richieste da UNA fonte, il repository dell'organizzazione.

Quindi ho alcune domande:

1. In questo caso è appropriato un approccio fork per sviluppatore? Sembra che potrebbe essere un po 'eccessivo. Non sono sicuro che abbiamo bisogno di un fork per ogni sviluppatore, a meno che non introduciamo sviluppatori che non hanno accesso push diretto e necessitano di tutto il loro codice rivisto. In tal caso, vorremmo istituire una politica del genere, solo per quegli sviluppatori. Quindi, qual è la migliore? Tutti gli sviluppatori in un unico repository o un fork per tutti?
2. Qualcuno ha esperienza con lo strumento hub, in particolare la funzione pull-request? Se eseguiamo un fork per sviluppatore (o anche per sviluppatori meno privilegiati) la funzione pull-request dell'hub opererà sulle richieste pull dal repository principale upstream (il repository dell'organizzazione?) O avrà un comportamento diverso?

EDIT
Ho fatto alcuni test con problemi, forchette e richieste pull e l'ho trovato. Se si crea un problema sul repository della propria organizzazione, quindi fork il repository dalla propria organizzazione al proprio account github, apportare alcune modifiche, unire al ramo master del proprio fork. Quando si tenta di eseguire hub -i <issue #>si ottiene un errore, User is not authorized to modify the issue. Quindi, apparentemente quel flusso di lavoro non funzionerà.

In questo caso è appropriato un approccio fork per sviluppatore? Sembra che potrebbe essere un po 'eccessivo. Non sono sicuro che abbiamo bisogno di un fork per ogni sviluppatore, a meno che non introduciamo sviluppatori che non hanno accesso push diretto e necessitano di tutto il loro codice rivisto. In tal caso, vorremmo istituire una politica del genere, solo per quegli sviluppatori. Quindi, qual è la migliore? Tutti gli sviluppatori in un unico repository o un fork per tutti?

Dipende dalle dimensioni della tua squadra, immagino. Lavoravo in una piccola squadra in cui avevamo un solo repository e le funzionalità avevano i loro rami all'interno di quel repository. Ha funzionato bene per noi.

Tuttavia, ora contribuisco regolarmente a un più ampio progetto open source in cui alcune decine di persone hanno accesso al repository centrale. Facciamo ancora tutti i principali sviluppi nei repository personali e inviamo le PR per le funzionalità in modo che il codice possa essere rivisto, anche se le correzioni dei bug possono essere inviate direttamente. Il repository principale porta solo rami master e di rilascio, mantenendolo libero da disordine. I rami delle caratteristiche si trovano in repository personali, quindi possono ancora essere visti da altri (creare PR per loro avviserà gli altri nel team che sta lavorando a una funzione). Posso raccomandare questo flusso di lavoro per qualsiasi progetto con più di una manciata di sviluppatori; l'unico aspetto negativo è la necessità di lavorare con più telecomandi.

L'approccio fork per sviluppatore è un ottimo approccio se si apprezzano le revisioni del codice e la qualità del codice. La cosa bella dell'utilizzo delle richieste pull è che sposta la responsabilità dal manutentore allo sviluppatore.

Lo sviluppatore desidera inserire il suo codice nel ramo principale e richiede la sua inclusione.

Questo è un contesto molto diverso rispetto al vecchio modello in cui le persone si impegnano, e in seguito il recensore ha dovuto dire loro "oh, questa cosa che hai fatto qualche settimana fa non era così buona, risolvila ora."

Usiamo questo modello nella nostra azienda. Le richieste pull hanno reso possibili richieste di codice, incoraggiano la discussione sul codice di altre persone e in generale hanno aiutato con la qualità del codice, anche con gli sviluppatori che sono stati i primi a contrastare il nuovo strumento. Ritengo che abbia anche indotto le persone a prendere più seriamente le revisioni del codice, perché il revisore deve unire attivamente il codice nel ramo principale, invece di dire semplicemente "ok" o "non ok" dopo che il codice è stato già impegnato.

Non farei tutto il fork e il branching per tutto. Questo è un buon modello per le gemme open source su github, ma il tuo modello è all'interno di un'organizzazione che normalmente avrebbe un più alto livello di fiducia sui cambiamenti.

Un punto importante del controllo del codice sorgente è che puoi vedere, backout, reverse, ecc. Le modifiche. Fare un numero elevato di forche e rami nella tua situazione è eccessivo IMHO.

Vorrei riservare filiali per cose come: aggiornamenti di versione, modifica di uno dei pezzi tecnologici, lavoro su un sottomodulo per 3 mesi che ha poco in comune con la base principale.

Potrei non sborsare affatto all'interno di un'organizzazione. Questa modalità sembra più adatta a progetti open source di natura diversa da quelli interni.

Vorrei spostare la tua attenzione su test e recensioni di codice. La gente sta scrivendo dei test? Sono buoni? Le revisioni del codice sono state fatte?