Perché usare le richieste pull invece di unire

Qual è il vantaggio di utilizzare le richieste pull invece di unire un ramo in master senza uno? Soprattutto in un team in cui tutti gli sviluppatori hanno pieno accesso al master.

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

Il più grande vantaggio è che offrono l'opportunità di rivedere il codice. La persona responsabile dell'esecuzione dell'estrazione può esaminare il codice e i test e assicurarsi che soddisfino qualsiasi tipo di linee guida dell'organizzazione o del team. Esistono anche altri motivi per la revisione del codice : istruzione, ricerca di difetti o miglioramenti, formazione incrociata del team sul sistema, che offre ai tester una visione in bianco del sistema.

Se la persona che esegue l'attrazione ha familiarità con l'architettura del sistema, può assicurarsi che i cambiamenti si adattino alla visione architettonica del sistema, specialmente se l'intero team potrebbe non avere la visione a lungo termine.

Sviluppare l'abitudine di utilizzare le richieste pull può anche aiutare il tuo team se decidi in futuro che l'intero team non dovrebbe avere accesso al master. Se la tua squadra cresce, e specialmente se hai membri della squadra che sono nuovi al prodotto e / o nuovi a Git, non dare loro accesso a master può essere più sicuro per l'integrità del prodotto.

Avendo fatto entrambe le diramazioni e le forcelle + richieste pull penso che le richieste pull offrano poco vantaggio quando tutti voi state sviluppando nello stesso team o azienda

Offrono un buon meccanismo e un'interfaccia per la revisione del codice, ma complicano e rallentano l'intero processo di "completamento delle cose". Soprattutto se hai molte piccole funzionalità, ognuna in attesa di revisione, fusione e poi tutte le altre vengono nuovamente fuse con il master per apportare le modifiche, ecc. Se hai delle funzionalità di grandi dimensioni, allora queste diventano difficili da rivedere, quindi rimani bloccato .

Detto questo, puoi fare richieste pull tra i rami nello stesso repository. Non è necessario effettuare il fork o disporre di autorizzazioni diverse.

Inoltre, devi considerare l'intera metodologia e il flusso di lavoro. Hai anche un sistema di ticketing, CI, test di accettazione automatizzati ecc? Le tue revisioni del codice forniscono un unico controllo vitale prima che i codici vengano pubblicati o sono solo esercizi di timbratura che vengono resi ridondanti da altri controlli nel tuo flusso di lavoro?

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

organizzazioni che progettano sistemi ... sono costrette a produrre progetti che sono copie delle strutture di comunicazione di queste organizzazioni.

Cosa c'entra questo con le richieste pull? Le richieste pull sono un importante canale di comunicazione in un nodo critico per il tuo codice. Forniscono un'opportunità per la revisione, i test automatizzati e il miglioramento prima che il codice passi alle fasi successive di test e produzione, in cui tali modifiche sono molto più difficili da annullare e sprecano molto più tempo per molte più persone.

Allo stesso modo, la Legge di Conway suggerisce che se si desidera avere un'architettura a microservizi con aree di responsabilità autonoma ben separate e interfacce ben definite, i canali di comunicazione della propria organizzazione dovrebbero riflettere l'architettura che si desidera ottenere. Ciò significa che i piccoli team di 5-10 persone dovrebbero avere accesso diretto e diretto a un determinato microservizio, e chiunque al di fuori di quel team dovrebbe essere tenuto a passare una richiesta pull. Questo assicura che le persone che hanno più familiarità con un microservizio siano quelle che lo stanno esaminando e fornendo consigli.

Quando hai una grande organizzazione con chiunque abbia un accesso diretto e diretto a tutto il mondo, i tuoi canali di comunicazione di minor resistenza ti stanno preparando a produrre una grande sfera di architettura di fango.

Le richieste pull possono sembrare un onere solo se non si scambia nulla in cambio. Ho lavorato in ambienti in cui non riesco a fare nulla per una settimana perché la build è sempre interrotta e ho lavorato in ambienti in cui qualcuno invia una richiesta pull e non devo nemmeno rivederla perché si sono rotti la build CI, e ti dico, valgono ogni secondo di sforzo.

Karl Bielefeldt ha esattamente ragione. Vorrei aggiungere: si tratta di qualità.

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

Ne vale davvero la pena.

Utilizziamo richieste pull per la revisione del codice - nessun codice deve essere unito al ramo di sviluppo principale (normalmente "sviluppo" nel nostro caso, ma a volte "master") senza essere stato sottoposto a 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.