Esiste uno scopo per utilizzare le richieste pull sul mio repository personale se sono l'unico sviluppatore?

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

Le richieste di pull possono essere utilizzate per tenere traccia della cronologia del progetto più facilmente. Una richiesta pull ha un ID di problema a cui è possibile fare riferimento da messaggi di commit e in un log delle modifiche, che consente di tornare facilmente e trovare 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 vergine), quando uniamo una richiesta pull, aggiungiamo un elemento a changelog , con una descrizione di una riga della modifica e un riferimento all'ID della richiesta di pull. Naturalmente, Pioneer ha diversi sviluppatori, ma lo stesso meccanismo potrebbe essere utile per uno sviluppatore che lavora da solo.

Questo può essere meno utile se si decide di attenersi a una cronologia di commit lineare (ridefinendo i rami delle funzionalità prima dell'unione, in modo che l'unione possa sempre essere eseguita come avanzamento rapido) e se si è molto disciplinati sull'editing e schiaccia i tuoi commit prima di unirli al master, perché in quel caso i singoli messaggi di commit possono essere usati come log delle modifiche in se stessi.

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

Nel tuo caso, qualcuno sei tu.

Come unico sviluppatore, dovresti comunque rivedere il tuo lavoro, rifattorizzarlo e unirlo a 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: novizio del 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 eviti il più possibile la conoscenza del dominio 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 di pull per gestirle se esegui comunque le attività di PR, ma potrebbe fornirti una struttura utile).

Inoltre, a volte scoprirò che il mio cambiamento non funziona, ma piuttosto che l'orrore di provare a tirarlo fuori dal master, forse ora mescolato con altre modifiche principali, posso semplicemente fare tutto in un ramo che può quindi ignorare / eliminare se inizia a andare storto. Questo è un enorme vantaggio.

Quindi dovresti lavorare nelle filiali e non eseguire il commit direttamente sul master finché non decidi di unire l'intero ramo.

Queste sono le linee guida, e non le regole, da seguire. Li spezzo intenzionalmente a volte. Ad esempio, ieri ho commesso una correzione errata al master.

Sembra che tu abbia filiali remote e filiali locali. Se trovi troppo spesso il sovraccarico di quel flusso di lavoro, puoi sempre lavorare su diverse funzionalità utilizzando le filiali locali senza doverle spingere.

In pratica 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 c'è un grande bisogno di usare il modello di richiesta di pull e commettere direttamente sul master dovrebbe funzionare bene. Quando il tuo progetto diventa incredibilmente efficace e decine o centinaia di sviluppatori ci stanno lavorando, scoprirai che ricevere le richieste pull dalle loro biforcazioni è un ottimo modo per tenere traccia del progetto.

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

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

Non ho necessariamente bisogno di tutti i controlli da passare per ogni commit, ma voglio che il capo del ramo principale controlli sempre. Penso che le richieste pull siano semplici (forse non l'unica).

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

Le richieste di pull vs git push alla fine arrivano a una cronologia singola o condivisa. Il repository principale è la fonte di tutte le modifiche, se altri ne derivano e potenzialmente possono apportare modifiche locali, quindi una richiesta push può causare problemi a tali utenti come l'albero derivante dalle modifiche.

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

Parte del motivo per cui stai mettendo il codice su github sarebbe quello di rendere il codice disponibile per la forgiatura, e tirare le richieste. Non hai mai saputo quando accadrà e mantenere coerenti le storie dei tuoi co-sviluppatori sarebbe un grande vantaggio.