Már jó ideje használom a GitHub-ot, és általában a jellemző ágakat toltam meg, majd elindítottam egy Pull kérést, amelyet magam is összevontam. Úgy találtam, hogy ez segített nyomon követni, hol egyesítettem az ágakat.
De nemrégiben egyre többet olvastam a Git működéséről, és rájöttem, hogy az egyesítés-elkötelezettségeket használhatom arra, hogy utaljak az egyesüléskor. elágazások.
Tehát mit kell tennem, ha a feature-branchet beolvasztom a masterbe:
Hajtsa végre az egyesítés-végrehajtást a masteren, majd nyomja felfelé VAGY Nyomja meg a helyi fiókot, és indítson húzási kérelmet?
Olvastam a következőt: Bevezetési kérelmek bemutatása 2 fős csapathoz – egyesítem a saját kéréseimet? és Mi folyik a munkában két emberrel egy projekten és Nyissam-e meg a hivatalos repó vagy a villám fiókjainak fiókjainak kéréseit? de úgy tűnik, egyikük sem válaszol arra, amit keresek.
Megjegyzések
- Pontosan mit érzel hiányolni ezekből a válaszokból?
- Az első abból a szempontból beszél róla, hogy a húzási kérelmeket szakértői felülvizsgálatra szánják. A második munkafolyamatot kínál. A harmadik még ' még nem is áll kapcsolatban.
- Ezt egy bevált módszerek vagy hogyan lehet fenntartani jó git előzmények szempontból.
- Amikor egyesítek egy PR-t, akkor az ág helyi összevonásával teszem ezt. Ez lehetővé teszi számomra, hogy megbizonyosodjak arról, hogy az egyesítés tiszta-e, és hogy az eredmény közzététele előtt újra futtassam a teszteket. A GitHub ' s lehívási kérelmek csak ennek a munkafolyamatnak a formalizálása, maga a Git nem rendelkezik PR-ek fogalmával.
- Amikor egy PR összevonásra kerül, egyesülést hoz létre elköteleződni a mester mellett, ezért nem gondolom, hogy ez bármi különbséget jelentene a git történetében. Tehát nem gondolom, hogy ' nem gondolom, hogy a parancssor és a Github kezelőfelület közötti személyes preferenciáktól eltekintve lenne oka egyik vagy másik felhasználására.
Válasz
git-merge mechanizmus:
A git merge feature használata, míg a masteren az feature ágat egyesíti master és merge-commit -et hoz létre (ha az elágazást nem lehet gyorsan továbbvinni) a git történetében. A készülő merge-commit kényszerítéséhez használja a --no-ff beállítást a merge.
Húzási kérelem egyesítésének mechanizmusa:
Amikor elindítunk egy lekérési kérelmet a GitHubon, létrehoz egy GitHub Issue ahol az emberek az összevonás előtt beszélhetnek és megvitathatják a PR-ben elkövetett kötelezettségvállalásokat. Ha egy PR összevonásra kerül a GitHubon, pontosan ugyanazt csinálja, mint a git merge feature.
Mit kell tennem ?
Tehát ami a történelmet illeti, nincs különbség a kettő között.
És ami a hozzájárulást illeti, a közreműködőknek nem lesz hogy bármi mást tegyek a két helyzetben. Ugyanazok (levonva a kedves kis csevegést).
Legjobb gyakorlatok:
És nem sikerült megtalálni a legjobb gyakorlatokat, de a logika szerint a PR-ek nem sokat segítenek, ha csak egy hozzászóló van egy adattárhoz.
@lxrec és @amon segítettek ebben a következtetésben lenni.
Megjegyzések
- Tipp: Előfordulhat, hogy a
git mergenem rögzít egyesítési elkötelezettséget, ha „gyors előre” képes végrehajtani. Az egyesítési elkötelezettség kikényszerítéséhez hozzáadhatja a--no-ffopciót. - Inkább a git-merge-et csinálom a helyi helyett, mint a githuib.com webhelyen, ha én bármi ilyesmire lenne szükségem a github.com-on. Nem szeretném, ha közvetlenül a master ágon tennék, inkább a nem master ágat választanám, amelyet előbb állomás módra lehet állítani, mielőtt elérhetővé tennék a termelés számára.
Válasz
Ahogy Ashhar mondta, technikailag és történelmileg nincs különbség. kis csapat inkább a közvetlen összevonást részesítem előnyben a PR létrehozásának extra lépése helyett. Ha azonban egy funkció felülvizsgálatra / visszajelzésre szorul, vagy ha WIP és több személy dolgozik rajta, akkor nyitok egy PR-t és hozzáadok egy a feladatok listája a PR leírásához.
Ne feledje, hogy a git merge gyors előretekerést használhat, ha nincsenek változtatások a masteren, ezért érdemes használni git merge --no-ff. Nem szoktam.
Összefoglalva tehát csak a PR-t használja s amikor megbeszélésre van szükséged. Ellenkező esetben csak egyesüljön közvetlenül.
Megjegyzések
- ' is érdemes megemlíteni, hogy a lehívási kérelem megvitatása és visszajelzése automatizált forrásokból származnak, valamint a csapat tagjai. Ha be van állítva egy CI-kiszolgáló, az összeépítési és tesztelési eredményeket adhat, így soha nem egyesít olyan dolgot, amely megszakítja a master alapját.