C'è uno scopo per usare le richieste pull sul mio repository se sono l'unico sviluppatore?

Quindi ho iniziato con un mio vero progetto su GitHub e le cose stanno andando abbastanza bene e le idee scorrono molto più velocemente di quanto pensassi inizialmente. Per mantenere le cose organizzate, ho installato alcuni rami in modo da poter sviluppare diverse funzionalità separatamente.

Ora quando spingo il mio ramo su GitHub, ho quella sezione in cui ho due pulsanti: Pull Requeste Comparecon il nome del ramo che ho premuto di recente. Comprendo lo scopo del Comparepulsante, ma non capisco perché vorrei creare una richiesta pull sul mio repository.

Qualcuno può spiegarmi perché lo farei? È utile fare una richiesta pull sul mio repository se sono l'unico sviluppatore?

Per molti (forse la maggior parte) singoli sviluppatori che lavorano da soli, la creazione di richieste pull non è probabilmente utile. Tuttavia, posso pensare ad almeno un potenziale motivo per farlo:

Le richieste pull possono essere utilizzate per tenere traccia della cronologia del progetto più facilmente. Una richiesta pull ha un ID problema a cui è possibile fare riferimento dai messaggi di commit e in un registro delle modifiche, che consente di tornare indietro e trovare facilmente il punto di unione e il set di commit uniti per una particolare modifica, senza dover conservare la funzionalità rami indefinitamente.

Ad esempio, in Pioneer (plug shameless), quando uniamo una richiesta pull, aggiungiamo un articolo al log delle modifiche, con una descrizione a una riga della modifica e un riferimento all'ID della richiesta pull. Naturalmente, Pioneer ha diversi sviluppatori, ma lo stesso meccanismo potrebbe essere utile per uno sviluppatore che lavora da solo.

Questo potrebbe essere meno utile se decidi di attenersi a una cronologia di commit lineare (riassegnando i rami delle caratteristiche prima dell'unione, in modo che l'unione possa sempre essere eseguita come avanzamento rapido) e se sei molto disciplinato sulla modifica e la compressione del tuo esegue il commit prima della fusione con il master, perché in tal caso i singoli messaggi di commit possono essere utilizzati come log delle modifiche in se stessi.

Le richieste pull vengono create in modo che qualcuno possa rivedere il lavoro, fare commenti, suggerimenti, apportare o richiedere modifiche e quindi unire il codice da padroneggiare.

Nel tuo caso qualcuno sei tu.

Come unico sviluppatore dovresti ancora rivedere il tuo lavoro, rifattorizzarlo e unirlo al master quando pronto.

Un approccio che uso molto è cercare di "indossare un altro cappello", "provare altre persone". Quindi siediti per un po 'e mettiti nella situazione di: principiante nel gruppo; sviluppatore junior; collega che hai rispettato in passato, ecc. Prova a guardarlo attraverso i loro occhi e prova a pensare semplicemente a cosa potresti fare per rendere il cambiamento più ovvio, meglio scritto con nomi ancora migliori che evitino il più possibile la conoscenza tribale e del dominio .

Quindi, come hai indicato, dovresti lavorare nei rami quando vuoi separare funzionalità e modifiche che non sono pronte per il master. Puoi fare tutto ciò nelle filiali (non hai nemmeno bisogno di richieste pull per gestirle se esegui comunque le attività di PR, ma può fornirti una struttura utile).

Inoltre, a volte scoprirò che il mio cambiamento non funziona, ma piuttosto che l'orrore di provare a tirarlo indietro dal master, forse ora mescolato con altri cambiamenti del master, posso semplicemente fare tutto in un ramo che posso quindi ignorare / cancella se inizia ad andare storto. Questo è un enorme vantaggio.

Quindi dovresti lavorare nei rami e non impegnarti direttamente nel master fino a quando non decidi di unire l'intero ramo.

Queste sono le linee guida - e non le regole - da seguire. Li rompo intenzionalmente a volte. Ad esempio, ieri ho commesso una correzione di battitura a master.

Sembra che tu abbia filiali remote e filiali locali. Se il sovraccarico di quel flusso di lavoro è eccessivo, puoi sempre lavorare su diverse funzionalità utilizzando le filiali locali senza spingerle.

Fondamentalmente si tratta di fare ciò che funziona per te. Lavorare con le filiali è un grande vantaggio per git, e github lo rende davvero facile, ma come sviluppatore solitario non è necessario utilizzare il modello di richiesta pull e impegnarsi direttamente in master dovrebbe funzionare bene. Quando il tuo progetto alla fine avrà un incredibile successo e decine o centinaia di sviluppatori ci stanno lavorando, scoprirai che ottenere richieste pull dalle loro forcelle è un ottimo modo per tenere traccia del progetto.

Le richieste pull vengono normalmente utilizzate per le revisioni del codice o per i contributi degli utenti con il proprio fork del progetto: per un singolo sviluppatore di un progetto non vedo davvero uno scopo.

Il motivo per cui lo faccio è che è un modo conveniente per assicurarsi che tutti i controlli automatici vengano superati (si compila, ha una formattazione corretta, i test unitari superano ...).

Non ho necessariamente bisogno di passare tutti i controlli per ogni commit, ma voglio che il capo del ramo principale passi sempre i controlli. Penso che le richieste pull siano il modo più semplice (forse non l'unico).

Più in generale, è un modo per collegare gli hook per completare le modifiche. I test sono un esempio; @ John ha menzionato la creazione di note sulla versione come altro esempio.

Le richieste pull vs git push alla fine si riducono a una storia individuale o condivisa. Il repository principale è la fonte di tutte le modifiche, se altre vengono estratte e apportano potenzialmente modifiche locali, una richiesta push può causare problemi a quegli utenti come l'albero da cui derivano dalle modifiche.

Il modello di richiesta pull (da filiali personalizzate o repository personali) serve come modo per fornire una cronologia coerente per tutti coloro che usano e derivano dal codice.

Parte del motivo per cui stai inserendo il codice su github potrebbe essere quello di rendere il codice disponibile per il fork e generare richieste. Non hai mai saputo quando accadrà e mantenere coerenti le storie dei tuoi co-sviluppatori sarebbe un grande vantaggio.