Uso GitHub da un po di tempo e di solito usavo spingere i miei rami di funzionalità e quindi avviare una richiesta di pull che io stesso ho unito. 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 branch.
Allora, cosa dovrei fare quando unisco un feature-branch in master:
Esegui un merge-commit sul master e poi trasferiscilo a monte OPPURE Eseguire il push del ramo locale e avviare una richiesta di pull?
Ho letto Presentazione delle richieste pull per un team di 2 persone: unire le mie richieste? e Qual è il flusso di lavoro con 2 persone su un progetto e Devo aprire richieste pull da un ramo nel repository ufficiale o nel mio fork? ma nessuno di loro sembra rispondere a quello che cerco.
Commenti
- Che cosa senti esattamente che manchi a queste risposte?
- Il primo ne parla dal senso che le richieste pull devono essere riviste tra pari. Il secondo offre un flusso di lavoro. Il terzo non è ' nemmeno correlato.
- Lo sto esaminando da Best practice o Come mantenere un buon punto di vista della cronologia di git .
- Quando unisco un PR, lo faccio unendo il ramo localmente. Ciò mi consente di assicurarmi che lunione 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.
- Quando un PR viene unito, produce ununione commit su master, quindi non ' penso che questo faccia alcuna differenza per la cronologia di git. Quindi non ' penso che ci sia alcun motivo per utilizzare luno o laltro a parte la tua preferenza personale tra la riga di comando e linterfaccia utente di Github.
Risposta
meccanismo git-merge:
Utilizzando git merge feature mentre in master si unisce il ramo feature a master e produce un merge-commit (se il ramo non può essere spostato rapidamente) nella cronologia di git. Per forzare la creazione di merge-commit, utilizza lopzione --no-ff con merge.
Meccanismo di richiesta pull di unione:
Quando avviamo una richiesta di pull su GitHub, viene creata una GitHub Issue dove le persone possono parlare e discutere i commit nel PR prima di unirlo. Quando un PR viene unito su GitHub, fa esattamente la stessa cosa di git merge feature.
Cosa devo fare ?
Quindi, per quanto riguarda la storia, non cè differenza tra i due.
E per quanto riguarda il contributo, i tuoi contributori non avranno fare qualcosa di diverso per le due situazioni. Sono gli stessi (meno la bella chiacchierata).
Best practice:
E non sono riuscito a trovare una best practice, ma la logica dice che le PR non sono molto utili se cè solo un singolo contributore a un repository.
@lxrec e @amon mi hanno aiutato a raggiungere questa conclusione.
Commenti
- Suggerimento:
git mergepotrebbe non registrare un commit di unione se può eseguire un “avanzamento veloce”. Per forzare un merge commit, puoi aggiungere lopzione--no-ff. - Preferisco fare git-merge in locale piuttosto che farlo su githuib.com, se avrei qualcosa di simile su github.com che preferirei non fare direttamente sul ramo master, preferirei prendere il ramo non master che può essere prima impostato in modalità di staging prima di renderlo disponibile per la produzione.
Risposta
Come ha detto Ashhar , tecnicamente e dal punto di vista storico non cè differenza. Per i progetti con un piccolo team Preferisco unire direttamente invece del passaggio aggiuntivo di creare un PR. Tuttavia, quando una funzione necessita di revisione / feedback o quando è “un WIP e più di una persona ci lavorerà, tendo ad aprire una PR e aggiungere un elenco delle attività nella descrizione del PR.
Tieni presente che git merge potrebbe utilizzare lavanzamento rapido se non ci sono modifiche al master, quindi potresti voler utilizzare git merge --no-ff. Tendo a non farlo.
Quindi, in sintesi, usa solo PR quando hai bisogno di una discussione. Altrimenti unisci direttamente.
Commenti
- ' vale anche la pena ricordare che la discussione e il feedback su una richiesta pull possono provengono da fonti automatizzate e da membri del team. Se hai un server CI configurato, può fornire risultati di build e test in modo da non unire mai qualcosa che interrompe il build on master.