En ny gren fra master
oprettes, vi kalder den test
.
Der er flere udviklere, som enten committerer til master
eller opretter andre grene og senere fletter dem sammen med master
.
Lad os sige, at arbejdet på test
tager flere dage, og du vil løbende holde test
opdateret med commits i master
.
Jeg ville lave git pull origin master
fra test
.
Spørgsmål 1: Er dette den rigtige fremgangsmåde? Andre udviklere kunne nemt have arbejdet på de samme filer som jeg har arbejdet btw.
Mit arbejde på test
er færdigt, og jeg er klar til at flette det tilbage til master
. Her er de to måder jeg kan komme i tanke om:
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
Jeg bruger ikke --rebase
, fordi rebase efter min opfattelse vil hente ændringerne fra master
og stable mine ændringer ovenpå dem, og derfor kan det overskrive ændringer, som andre har lavet.
Spørgsmål 2: Hvilken af disse to metoder er den rigtige? Hvad er forskellen der?
Målet med alt dette er at holde min test
gren opdateret med de ting der sker i master
og senere kan jeg flette dem tilbage i master
i håb om at holde tidslinjen så lineær som muligt.
Sådan ville jeg gøre det
git checkout master
git pull origin master
git merge test
git push origin master
Hvis jeg har en lokal filial fra en fjernfilial, føler jeg mig ikke tryg ved at fusionere andre filialer end denne med fjernfilialen. Jeg ville heller ikke skubbe mine ændringer, før jeg er tilfreds med det, jeg vil skubbe, og jeg ville heller ikke skubbe ting overhovedet, som kun er for mig og mit lokale repository. I din beskrivelse ser det ud til, at test
kun er for dig? Så ingen grund til at publicere den.
git forsøger altid at respektere dine og andres ændringer, og det vil --rebase
også gøre. Jeg tror ikke jeg kan forklare det hensigtsmæssigt, så tag et kig på the Git book - Rebasing eller git-ready: Intro into rebasing for en lille beskrivelse. It's a quite cool feature
Dette er et meget praktisk spørgsmål, men alle de ovenstående svar er ikke praktiske.
Som
git checkout master
git pull origin master
git merge test
git push origin master
Denne fremgangsmåde har to problemer:
Det er usikkert, fordi vi ikke ved, om der er nogen konflikter mellem testgren og mastergren.
Det ville "presse" alle testcommits ind i ét mergecommit på master; det vil sige, at vi på mastergrenen ikke kan se alle ændringslogs for testgrenen.
Så når vi har mistanke om, at der er nogle konflikter, kan vi foretage følgende Git-operationer:
git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test
Test merge
før commit
, undgå en fast-forward commit med --no-ff
,
Hvis der opstår en konflikt, kan vi køre git status
for at tjekke detaljer om konflikterne og forsøge at løse
git status
Når vi har løst konflikterne, eller hvis der ikke er nogen konflikt, commit
og push
vi dem
git commit -m 'merge test branch'
git push
Men på denne måde vil vi miste den ændringshistorik, der er logget i testgrenen, og det vil gøre mastergrenen svær for andre udviklere at forstå projektets historie.
Så den bedste metode er at bruge rebase
i stedet for merge
(antag, når vi i denne tid har løst grenkonflikterne).
Følgende er et simpelt eksempel, for avancerede operationer henvises til 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
Jep, når du har lavet uppers, vil alle Test branch's commits blive flyttet over på Master-grenens hoved. Den store fordel ved rebasing er, at du får en lineær og meget renere projekthistorik.
Det eneste du skal undgå er: brug aldrig rebase
på en offentlig gren, som f.eks. master-grenen.
Gør aldrig operationer som følgende:
git checkout master
git rebase -i test
Detaljer for https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing
appendix:
Hverken en rebase eller en sammenlægning bør overskrive andres ændringer (medmindre du vælger at gøre det, når du løser en konflikt).
Den sædvanlige fremgangsmåde under udvikling er
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
Når du er klar til at flette tilbage til master,
git checkout master
git log ..test # if you're curious
git merge test
git push
Hvis du er bekymret for at ødelægge noget ved sammenlægningen, er git merge --abort
der for dig.
Det er fjollet at bruge push og derefter pull som en måde at fusionere på. Jeg er heller ikke sikker på, hvorfor du skubber test til origin.