Repository di organizzazione Github, problemi, più sviluppatori e forking: le migliori pratiche del flusso di lavoro

Question

Repository di organizzazione Github, problemi, più sviluppatori e forking: le migliori pratiche del flusso di lavoro

#1 da (6 voti)
#2 da (2 voti)
#3 da (1 voti)

14

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

Abbiamo un account di organizzazione su github con repository privati. Vogliamo utilizzare le funzionalità native di problemi / richieste pull di github (le richieste pull sono fondamentalmente esattamente ciò che vogliamo per quanto riguarda le revisioni del codice e le discussioni sulle funzionalità). Abbiamo trovato lo strumento hub di defunkt che ha una piccola caratteristica di essere in grado di convertire un problema esistente in una richiesta pull e associare automaticamente il ramo corrente con esso.

Mi chiedo se sia una buona pratica che ogni sviluppatore dell'organizzazione imponga al repository dell'organizzazione di eseguire il proprio lavoro sulle funzionalità / correzioni di errori / ecc. Questo sembra un flusso di lavoro piuttosto solido (dato che è fondamentalmente il progetto open source ogni su github) ma vogliamo essere sicuri di poter tenere traccia dei problemi e ottenere le richieste da una fonte, il repository dell'organizzazione .

Quindi ho alcune domande:

L'approccio di fork-per-developer è appropriato in questo caso? 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 diretto al push e hanno bisogno di rivedere tutto il loro codice. In tal caso, vorremmo istituire una politica del genere, solo per quegli sviluppatori. Quindi, che è meglio? Tutti gli sviluppatori in un unico repository o un fork per tutti?
Qualcuno ha esperienza con lo strumento hub, in particolare con la funzione pull-request? Se facciamo un fork-per-developer (o anche per gli sviluppatori meno privilegiati) la funzionalità pull-request dell'hub funziona sulle richieste pull dal repository master upstream (il repository dell'organizzazione?) O ha un comportamento diverso?

Modifica
Ho fatto alcuni test con problemi, fork e richieste di pull e l'ho trovato. Se si crea un problema nel repository della propria organizzazione, quindi si esegue il fork del repository dalla propria organizzazione al proprio account github, si apportano alcune modifiche, si uniscono al ramo master della propria forcella. Quando provi a eseguire hub -i <issue #> ottieni un errore, User is not authorized to modify the issue . Quindi, apparentemente il flusso di lavoro non funzionerà.

git teamwork version-control workflows github

posta Jim Rubenstein 28.02.2012 - 00:10

fonte

3 risposte

Leggi altre domande sui tag git teamwork version-control workflows github

Condivisione di oggetti DTO tra microservizi Perché Microsoft ha abbandonato il modello RESX per RESW nelle applicazioni di Windows Store?

score 6 · Answer 1

Is a fork-per-developer approach appropriate in this case? It seems like it could be a little overkill. I'm not sure that we need a fork for every developer, unless we introduce developers who don't have direct push access and need all their code reviewed. In which case, we would want to institute a policy like that, for those developers only. So, which is better? All developers in a single repository, or a fork for everyone?

Dipende dalla scala della tua squadra, immagino. Lavoravo in un piccolo team in cui avevamo appena un unico repository e le funzionalità hanno ottenuto le loro filiali all'interno del repository. Questo ha funzionato bene per noi.

Tuttavia, ora contribuisco regolarmente a un progetto open source più ampio in cui poche dozzine di persone hanno accesso al repository centrale. Continuiamo a fare tutti i principali sviluppi nei repository personali e a inviare le PR per le funzionalità in modo che il codice possa essere rivisto, sebbene le correzioni dei bug possano essere inserite direttamente. Il repository principale supporta solo i rami master e release, mantenendoli liberi da ingombri. I rami delle funzionalità sono nei repository personali, quindi possono essere ancora visti dagli altri (facendo in modo che i primi PR li segnalino agli altri membri del team che lavorano su una funzionalità). Posso raccomandare questo flusso di lavoro per qualsiasi progetto con più di una manciata di sviluppatori; l'unico lato negativo è dover lavorare con più telecomandi.

score 2 · Answer 2

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

Lo sviluppatore vuole ottenere il suo codice nel ramo principale e richiede l'inclusione.

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

Usiamo questo modello nella nostra azienda. Le richieste di pull hanno reso possibili le 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 erano i primi contro il nuovo strumento. Sento che anche le persone prendono le recensioni sul codice più seriamente, perché il revisore deve fondere attivamente il codice nel ramo principale, invece di dire "ok" o "non ok" dopo che il codice era già stato eseguito.

score 1 · Answer 3

Non farei tutto il biforcarsi e ramificarmi per tutto. Questo è un buon modello per le gemme open source su github, ma il tuo modello si trova all'interno di un'organizzazione che normalmente avrebbe un livello più elevato di fiducia nelle modifiche.

Un punto importante del controllo del codice sorgente è che puoi vedere, fare retromarcia, invertire, ecc. Fare un numero elevato di forchette e rami nella tua situazione è eccessivo. IMHO.

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

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

Passerei il focus a test e revisioni del codice. La gente sta scrivendo dei test? Sono buoni? Le revisioni del codice sono state fatte?