Mi a legjobb (és legbiztonságosabb) módja egy Git ág egyesítésének a masterbe?

Létrejön egy új ág a "master"-ből, ezt hívjuk "teszt"-nek.

Számos fejlesztő van, akik vagy a master-be commitolnak, vagy más ágakat hoznak létre, és később egyesülnek a master-be.

Tegyük fel, hogy a test-en való munka több napig tart, és a test-t folyamatosan frissíteni akarjuk a master-en belüli commitokkal.

Én a git pull origin master-t csinálnám a test-ből.

Kérdés 1: Ez a helyes megközelítés? Más fejlesztők is könnyen dolgozhattak volna ugyanazokon a fájlokon, mint amin én dolgoztam btw.


A test-en végzett munkám befejeződött, és készen állok arra, hogy visszaolvassam a master-be. Itt van a két lehetőség, amire gondolni tudok:

A:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B:

git checkout test
git pull origin master
git checkout master
git merge test

Azért nem használom a --rebase-t, mert az én értelmezésem szerint a rebase megkapja a master változtatásait, és az enyémet rápakolja, így felülírhatja a mások által végzett változtatásokat.

Kérdés 2: A két módszer közül melyik a helyes? Mi a különbség?

A cél mindezzel az, hogy a test ágamat naprakészen tartsam a master-ben történt dolgokkal, és később visszaolvassam őket a master-be, remélve, hogy az idővonal minél lineárisabb marad.

Megoldás

Hogyan csinálnám ezt

git checkout master
git pull origin master
git merge test
git push origin master

Ha van egy helyi ágam egy távoli ágból, akkor nem'zem jól, ha más ágakat egyesítek, mint ez a távoli ág. Továbbá nem tolnám a változtatásaimat, amíg nem vagyok elégedett azzal, amit szeretnék tolni, és egyáltalán nem tolnék olyan dolgokat, amelyek csak nekem és a helyi repositorymnak szólnak. A leírásodból úgy tűnik, hogy a test csak neked szól? Tehát nincs okod közzétenni.

A git mindig igyekszik tiszteletben tartani a te és mások változtatásait, és a --rebase is ezt fogja tenni. Nem hiszem, hogy megfelelően el tudom magyarázni, ezért nézd meg a Git könyv - Rebasing vagy git-ready: Intro into rebasing egy kis leírást. Ez egy elég klassz funkció.

Kommentárok (19)

Ez egy nagyon gyakorlatias kérdés, de a fenti válaszok mindegyike nem gyakorlatias.

Mint például a

git checkout master
git pull origin master
git merge test
git push origin master

Ennek a megközelítésnek két problémája van:

  1. Nem biztonságos, mert nem tudjuk, hogy vannak-e konfliktusok a teszt ág és a master ág között.

  2. Ez "összepréselné" az összes teszt commitot egy egyesített commitba a master ágon; vagyis a master ágon nem láthatjuk a teszt ág összes változásnaplóját.

Tehát, ha azt gyanítjuk, hogy konfliktusok lennének, akkor a következő git műveleteket végezhetjük:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Teszteljük a merge-t a commit előtt, elkerülve a gyors commitot a --no-ff-vel,

Ha konfliktusra bukkanunk, futtathatjuk a git status-t, hogy ellenőrizzük a konfliktus részleteit és megpróbáljuk megoldani.

git status

Ha megoldottuk a konfliktusokat, vagy ha nincs konfliktus, akkor commit és push.

git commit -m 'merge test branch'
git push

De így elveszítjük a teszt ágban naplózott változások előzményeit, és a master ágban a többi fejlesztő számára nehéz lesz megérteni a projekt előzményeit.

Tehát a legjobb módszer a rebase használata a merge helyett (tegyük fel, hogy ha ez idő alatt megoldottuk az ágkonfliktusokat).

Az alábbiakban egy egyszerű példát mutatunk be, a haladó műveletekhez kérjük, olvassa el a http://git-scm.com/book/en/v2/Git-Branching-Rebasing weboldalt.

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Igen, amikor a feljebbvalók elkészültek, az összes Test ág's commit átkerül a Master ág fejére. Az átrakás legfőbb előnye, hogy lineáris és sokkal tisztább projekttörténetet kapsz.

Az egyetlen dolog, amit el kell kerülnöd: soha ne használd az rebase-t nyilvános ágon, mint a master ág.

Soha ne végezz olyan műveleteket, mint a következő:

git checkout master
git rebase -i test

Részletek a https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing számára.

függelék:

Kommentárok (8)

Sem az újraalapozásnak, sem az egyesítésnek nem szabad felülírnia senki módosításait (kivéve, ha úgy döntesz, hogy ezt teszed egy konfliktus feloldásakor).

A szokásos megközelítés fejlesztés közben a következő

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

Amikor készen állsz a masterbe való visszaolvasztásra,

git checkout master
git log ..test # if you're curious
git merge test
git push

Ha aggódsz, hogy valamit elrontasz az egyesítés során, a git merge --abort ott van neked.

A push, majd a pull használata az egyesítés eszközeként butaság. Azt sem értem, hogy miért tolod a tesztet az origóba.

Kommentárok (7)