Perché utilizzare le richieste pull invece di unire

Le richieste pull forniscono controlli e contrappesi, anche se chiunque può spingere al master.

Il più grande vantaggio è che offrono un'opportunità per la revisione del codice. La persona che è responsabile per l'esecuzione del tiro può guardare il codice e le prove e assicurarsi che soddisfino qualsiasi tipo di linee guida che l'organizzazione o il team ha. Ci sono anche altri motivi per la revisione del codice - educazione, individuazione di difetti o miglioramenti, formazione incrociata della squadra sul sistema , dando ai tester una visuale bianca del sistema.

Se la persona che esegue il tiro ha familiarità con l'architettura del sistema, allora può assicurarsi che le modifiche siano compatibili con la visione architettonica del sistema, specialmente se l'intero team non può avere una visione a lungo termine.

L'abitudine a utilizzare le richieste pull può anche aiutare la tua squadra se in futuro deciderai che l'intero team non dovrebbe avere accesso al master. Se il tuo team diventa più grande e soprattutto se hai membri del team che sono nuovi sul prodotto e / o nuovi su Git, non concedere loro l'accesso al master può essere più sicuro per l'integrità del prodotto.

Avendo fatto entrambe le funzioni di ramificazione e fork + richieste pull, penso che le richieste pull offrano un piccolo vantaggio quando tutti si stanno sviluppando nella stessa squadra o azienda

Offrono un buon meccanismo e un'interfaccia per la revisione del codice, ma complicano e rallentano anche il processo di "completamento della roba". Soprattutto se hai molte piccole funzionalità, ognuna in attesa di revisione, fusione e poi tutte le altre sono unite con il master di nuovo per estrarre le modifiche ecc. Se hai grandi funzionalità anche se poi diventano difficili da recensire, così sei colto da un vincolo .

Detto questo puoi fare pull richieste tra filiali sullo stesso repo. Non devi forchetta, o avere permessi diversi.

Inoltre devi considerare l'intera metodologia e il tuo flusso di lavoro. Avete anche un sistema di ticketing, IC, test di accettazione automatizzati, ecc.? Le tue revisioni del codice forniscono un controllo unico essenziale prima che i codici siano pubblicati, o sono solo esercizi di timbri che sono resi superflui da altri controlli nel tuo flusso di lavoro?

C'è un'osservazione chiamata Legge di Conway che afferma:

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

Che cosa ha a che fare con le richieste pull? Le richieste di pull sono un canale di comunicazione importante in un nodo critico per il tuo codice. Offrono un'opportunità di revisione, test automatizzati e miglioramenti prima che il codice passi alle fasi successive di test e produzione, laddove tali modifiche sono molto più difficili da eseguire e sprecano molto più tempo di molte più persone.

Allo stesso modo, la legge di Conway suggerisce che se si desidera avere un'architettura di microservizi con aree di responsabilità autonoma e interfacce ben definite, i canali di comunicazione della propria organizzazione dovrebbero riflettere l'architettura che si desidera raggiungere. Ciò significa che piccole squadre di 5-10 persone dovrebbero avere l'accesso diretto a qualsiasi microservizio dato, e chiunque all'esterno di quel team dovrebbe essere richiesto di passare attraverso una richiesta di pull. Ciò garantisce che le persone più familiari con un microservizio siano quelle che lo esaminano e consigliano.

Quando hai una grande organizzazione con chiunque abbia accesso diretto a commit ovunque, i tuoi canali di comunicazione di minor resistenza ti stanno preparando a produrre una grande palla di architettura di fango.

Le richieste di pull sembrano solo un peso se non si scambiano nulla in cambio. Ho lavorato in ambienti in cui non riesco a ottenere nulla per una settimana perché la build è sempre interrotta e ho lavorato in ambienti in cui qualcuno invia una richiesta di pull e non ho nemmeno bisogno di rivederlo perché si è rotto la build CI, e ti dico, valgono ogni secondo di sforzo.

Karl Bielefeldt ha esattamente ragione. Vorrei aggiungere: è tutto sulla qualità.

Molti negozi (la maggior parte?) non hanno processi formali per governare lo sviluppo, il che si traduce in: "Ho lavorato in ambienti in cui non riesco a ottenere nulla per una settimana perché la build è sempre interrotta e ho lavorato in ambienti in cui qualcuno invia una richiesta di pull e non ho nemmeno bisogno di rivederlo perché ha rotto la build di CI e, ti dico, valgono ogni secondo di sforzo. "

Ne vale davvero la pena.

Usiamo le richieste pull per la revisione del codice: nessun codice deve essere unito al ramo di sviluppo principale (normalmente "sviluppa" nel nostro caso, ma a volte "master") senza essere passato attraverso una richiesta pull. Non è difficile applicarlo con i controlli del repository, ma è perché non è necessario: i nostri sviluppatori sono abbastanza maturi da non abusare del processo.