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.
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ó.
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:
Nem biztonságos, mert nem tudjuk, hogy vannak-e konfliktusok a teszt ág és a master ág között.
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:
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.