Vytvorí sa nová vetva z master
, nazveme ju test
.
Existuje niekoľko vývojárov, ktorí buď odovzdávajú revízie do vetvy master
, alebo vytvárajú iné vetvy a neskôr ich zlučujú do vetvy master
.
Povedzme, že práca na vetve test
trvá niekoľko dní a vy chcete, aby sa vetva test
priebežne aktualizovala revíziami vo vnútri vetvy master
.
Urobil by som git pull origin master
z test
.
Otázka 1: Je to správny prístup? Ostatní vývojári mohli ľahko pracovať na rovnakých súboroch ako ja btw.
Moja práca na teste
je hotová a som pripravený ju zlúčiť späť do mastera
. Tu sú dva spôsoby, ktoré ma napadajú:
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
Nepoužívam --rebase
, pretože podľa môjho chápania rebase získa zmeny z master
a navrství na ne moje, čím by mohlo dôjsť k prepísaniu zmien, ktoré vykonali iní ľudia.
Otázka 2: Ktorá z týchto dvoch metód je správna? Aký je v tom rozdiel?
Cieľom tohto všetkého je, aby moja vetva test
bola stále aktualizovaná o veci, ktoré sa dejú vo vetve master
, a neskôr by som ich mohol zlúčiť späť do vetvy master
, pričom dúfam, že časová os bude čo najlineárnejšia.
Ako by som to urobil ja
git checkout master
git pull origin master
git merge test
git push origin master
Ak mám lokálnu vetvu zo vzdialenej vetvy, necítim sa pohodlne pri zlučovaní iných vetiev ako tejto so vzdialenou. Takisto by som nepostupoval svoje zmeny, kým nebudem'spokojný s tým, čo chcem postúpiť, a tiež by som vôbec nepostupoval veci, ktoré sú určené len pre mňa a môj lokálny repozitár. Vo vašom popise sa zdá, že test
je len pre vás? Takže nie je dôvod ho zverejňovať.
Git sa vždy snaží rešpektovať tvoje a cudzie zmeny, a tak bude aj --rebase
. Nemyslím si, že to dokážem vhodne vysvetliť, takže si pozrite knihu Git - Rebasing alebo git-ready: Intro into rebasing, kde je to trochu popísané. Je to celkom fajn funkcia
Toto je veľmi praktická otázka, ale všetky vyššie uvedené odpovede nie sú praktické.
Ako napríklad .
git checkout master
git pull origin master
git merge test
git push origin master
Tento prístup má dva problémy:
Je nebezpečný, pretože nevieme, či medzi testovacou a hlavnou vetvou nie sú konflikty.
To by "stlačilo" všetky testovacie revízie do jednej zlučovacej revízie na master; to znamená, že na master vetve nevidíme všetky záznamy zmien testovacej vetvy.
Takže keď máme podozrenie, že by mohlo dôjsť k nejakým konfliktom, môžeme vykonať nasledujúce operácie git:
git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test
Pred odovzdaním
otestujte merge
, vyhnite sa rýchlemu odovzdaniu pomocou --no-ff
,
Ak sa vyskytne konflikt, môžeme spustiť git status
, aby sme zistili podrobnosti o konfliktoch a pokúsili sa ich vyriešiť
git status
Po vyriešení konfliktov, alebo ak sa konflikt nevyskytol, odošleme
a odpíšeme
ich
git commit -m 'merge test branch'
git push
Ale týmto spôsobom sa stratí história zmien zaznamenaných v testovacej vetve a pre ostatných vývojárov by bolo ťažké pochopiť históriu projektu vo vetve master.
Takže najlepšou metódou je použiť rebase
namiesto merge
(predpokladajme, že v tomto čase sme vyriešili konflikty vetiev).
Nasleduje jedna jednoduchá ukážka, pokročilé operácie nájdete na adrese http://git-scm.com/book/en/v2/Git-Branching-Rebasing.
git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test
Áno, keď budete mať hotové horné verzie, všetky revízie vetvy Test's sa presunú na hlavu vetvy Master. Hlavnou výhodou rebasingu je, že získate lineárnu a oveľa prehľadnejšiu históriu projektu.
Jediná vec, ktorej sa musíte vyhnúť, je: nikdy nepoužívajte rebase
na verejnej vetve, ako je napríklad master vetva.
Nikdy nevykonávajte operácie, ako napríklad:
git checkout master
git rebase -i test
Podrobnosti na https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing
príloha: "Príručka pre deti a mládež" (v anglickom jazyku)
Ani rebase, ani merge by nemali prepisovať nikoho zmeny (pokiaľ sa tak nerozhodnete pri riešení konfliktu).
Obvyklý prístup pri vývoji je
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
Keď'ste pripravení na zlúčenie späť do master,
git checkout master
git log ..test # if you're curious
git merge test
git push
Ak'sa obávate, že pri zlučovaní niečo pokazíte, je tu pre vás git merge --abort
.
Používať push a potom pull ako prostriedok na zlučovanie je hlúpe. Tiež si nie som istý, prečo tlačíte test do originu.