Folosesc GitHub de ceva timp și obișnuiam să-mi împing ramurile de caracteristici și apoi să încep o Pull Request pe care am combinat-o eu. Am constatat că m-a ajutat să țin cont de locul în care am fuzionat sucursalele.
Dar recent am citit din ce în ce mai multe despre modul în care funcționează Git și mi-am dat seama că pot folosi comitetele de îmbinare pentru a mă referi când am fuzionat branches.
Deci, ce ar trebui să fac atunci când fuzionează o caracteristică-branch în master:
Efectuează un merge-commit pe master și apoi împinge-l în amonte SAU Împingeți ramura locală și începeți o cerere de extragere?
Am citit Introducerea cererilor Pull pentru o echipă de 2 persoane – îmbinați propriile cereri? și Care este fluxul de lucru cu 2 persoane într-un proiect și Ar trebui să deschid cereri de extragere dintr-o sucursală din repo-ul oficial sau din furculița mea? dar niciunul dintre ei nu pare să răspundă la ceea ce caut.
Comentarii
- Ce anume simți că lipsește din aceste răspunsuri?
- Primul vorbește despre asta din sensul că cererile de extragere sunt menite să fie evaluate de colegi. Al doilea oferă un flux de lucru. Al treilea nu este ' nici măcar înrudit.
- Mă uit la asta din Cele mai bune practici sau Cum să mențin un bun punct de vedere istoric git .
- Când fuzionez un PR, o fac prin fuzionarea sucursalei la nivel local. Acest lucru îmi permite să mă asigur că îmbinarea se aplică în mod curat și să reexecut testele înainte de a publica rezultatul. Solicitările de extragere GitHub ' sunt doar o formalizare a acestui flux de lucru, Git în sine nu are un concept de PR-uri.
- Când un PR se îmbină, produce o îmbinare să mă angajez la master, așa că nu ' cred că asta face vreo diferență în istoria git. Astfel, nu ' nu cred că există vreun motiv pentru a utiliza unul sau altul în afară de preferința dvs. personală între linia de comandă și interfața Github.
Răspuns
mecanism git-merge:
Utilizarea git merge feature în timp ce pe master combină ramura feature cu master și produce un merge-commit (dacă ramura nu poate fi redirecționată rapid) în istoricul git. Pentru a forța realizarea unei merge-commit, utilizați opțiunea --no-ff cu merge.
Mecanismul Merge Pull Request:
Când începem o Pull Request pe GitHub, se creează un GitHub Issue unde oamenii pot vorbi și discuta comitetele din PR înainte de a le combina. Când un PR este fuzionat pe GitHub face exact același lucru ca și git merge feature.
Ce ar trebui să fac ?
Deci, în ceea ce privește istoria, nu există nicio diferență între cele două.
Și în ceea ce privește contribuția, contribuitorii dvs. nu vor avea să facă ceva diferit pentru cele două situații. Sunt la fel (minus micul chat frumos).
Cele mai bune practici:
Și nu am putut găsi cele mai bune practici, dar logica spune că PR-urile nu sunt de mare ajutor dacă există un singur contribuitor la un depozit.
@lxrec și @amon m-au ajutat să ajung la această concluzie.
Comentarii
- Sfat:
git merges-ar putea să nu înregistreze un commit de îmbinare dacă poate face un „avans rapid”. Pentru a forța un commit de îmbinare, puteți adăuga opțiunea--no-ff. - Prefer să fac git-merge pe local decât să o fac pe githuib.com, dacă ar trebui să fac ceva de acest gen pe github.com Aș prefera să nu fac direct pe filiala master, aș prefera să iau filiala non-master, care poate fi setată mai întâi în modul de etapizare înainte de a o face disponibilă pentru producție.
Răspuns
După cum a spus Ashhar , din punct de vedere tehnic și istoric nu există nicio diferență. Pentru proiectele cu o echipa mică prefer să fuzionez direct în loc de pasul suplimentar de creare a unui PR. Totuși, atunci când o caracteristică are nevoie de recenzie / feedback sau când este „WIP și mai multe persoane vor lucra la aceasta, tind să deschid un PR și să adaug un lista sarcinilor la descrierea PR-ului.
Rețineți că git merge ar putea utiliza avansul rapid dacă nu există modificări de master, deci este posibil să doriți să utilizați git merge --no-ff. Nu tind.
Deci, în rezumat, folosiți doar PR când ai nevoie de discuții. În caz contrar, fuzionează direct.
Comentarii
- Merită, de asemenea, ' că discuția și feedback-ul cu privire la o cerere pull pot provin din surse automate, precum și din membrii echipei. Dacă aveți configurat un server CI, acesta poate oferi rezultate de compilare și testare, astfel încât să nu îmbinați niciodată ceva care rupe construcția pe master.