È meglio avviare una richiesta pull o eseguire un commit di unione locale sul master?

Sto usando GitHub da un po 'di tempo e di solito usavo spingere i miei rami di funzionalità e quindi avviare una richiesta pull che ho unito io stesso. Ho scoperto che mi ha aiutato a tenere traccia di dove ho unito i rami.

Ma recentemente ho letto sempre di più su come funziona Git e mi sono reso conto che posso usare i merge-commit per fare riferimento a quando ho unito i rami.

Quindi, cosa devo fare quando unisco un ramo di funzionalità nel master:
esegui un commit di merge sul master e poi spingilo a monte OPPURE Spingi il ramo locale e avvia una richiesta pull?

Ho letto Presentazione delle richieste pull per un team di 2 persone: unisci le mie richieste? e qual è il flusso di lavoro con 2 persone su un progetto e devo aprire le richieste pull da una filiale sul repository ufficiale o sul mio fork? ma nessuno di loro sembra rispondere a quello che sto cercando.

— Ashhar Hasan
fonte

Cosa pensi esattamente che manchi di quelle risposte?

— RubberDuck,

Il primo ne parla dal senso che le richieste pull devono essere sottoposte a peer review. Il secondo offre un flusso di lavoro. Il terzo non è nemmeno correlato.

— Ashhar Hasan,

Sto guardando questo da un Best Practices o come mantenere un buon punto di vista storico git .

— Ashhar Hasan,

Quando unisco un PR, lo faccio unendo il ramo localmente. Questo mi consente di assicurarmi che l'unione si applichi in modo pulito e di rieseguire i test prima di pubblicare il risultato. Le richieste pull di GitHub sono solo una formalizzazione di questo flusso di lavoro, Git stesso non ha un concetto di PR.

— amon,

Quando un PR viene unito, produce un commit di unione sul master, quindi non credo che ciò faccia alcuna differenza nella cronologia git. Quindi non penso che ci sia alcun motivo per usare l'uno o l'altro a parte le tue preferenze personali tra la riga di comando e l'interfaccia utente di Github.

— Ixrec,

Risposte:

meccanismo di git-merge:
Usando git merge featurementre sul padrone fonde il ramo featureper mastere produce un merge-commit(se il tralcio non può essere veloce-inoltrato) nella storia git. Per forzare un merge-commitfatto, usa l' --no-ffopzione con merge.

Meccanismo di richiesta pull pull:
quando iniziamo una richiesta pull su GitHub, viene creato un punto in GitHub Issuecui le persone possono parlare e discutere gli commit nel PR prima di unirlo. Quando un PR viene unito su GitHub, fa esattamente la stessa cosa di git merge feature.

Cosa dovrei fare?
Quindi, per quanto riguarda la storia, non c'è differenza tra i due.
E per quanto riguarda il contributo, i tuoi collaboratori non dovranno fare nulla di diverso per le due situazioni. Sono gli stessi (meno la bella chiacchierata).

Best Practices:
e io ero in grado di trovare una best practice ma la logica dice che PR non sono molto utili se c'è solo una persona singola al repository.

@lxrec e @amon mi hanno aiutato a raggiungere questa conclusione.

— Ashhar Hasan
fonte

Suggerimento: git mergepotrebbe non essere possibile registrare un commit di unione se può eseguire un "avanzamento rapido". Per forzare un commit di unione, è possibile aggiungere l' --no-ffopzione.

— amon,

Preferisco fare git-merge su local piuttosto che farlo su githuib.com, se dovessi fare qualcosa di simile su github.com preferirei non fare direttamente sul ramo master, preferirei prendere un ramo non master che può prima essere impostato sulla modalità di gestione temporanea prima di renderlo disponibile per la produzione.

— Ciasto piekarz,

Come ha detto Ashhar , tecnicamente e nella storia non c'è differenza. Per i progetti con un piccolo team preferisco fondere direttamente anziché il passaggio aggiuntivo della creazione di un PR. Tuttavia, quando una funzione necessita di revisione / feedback o quando è un WIP e più di una persona ci lavora, tendo ad aprire un PR e ad aggiungere un elenco di attività alla descrizione del PR.

Nota che git mergepotrebbe essere utilizzato l'avanzamento rapido se non ci sono modifiche al master, quindi potresti voler usare git merge --no-ff. Tendo a non farlo.

Quindi, in sintesi, utilizzare le PR solo quando è necessario discutere. Altrimenti basta unire direttamente.

— Louay Alakkad
fonte

Vale anche la pena ricordare che la discussione e il feedback su una richiesta pull possono provenire da fonti automatizzate e dai membri del team. Se hai configurato un server CI, può fornire risultati di build e test in modo da non unire mai qualcosa che interrompe la build sul master.

— Eric