Die verspreide weergawe-beheerstelsel genaamd Git het die manier waarop ontwikkelaars dink om kode saam te smelt en te vertak, verander in vergelyking met die vorige weergawe-beheerstelsels soos CVS en SVN.
Met Git het hierdie bedrywighede betreklik maklik en vinnig geword om te doen. Hierdie stelsel stel ontwikkelaars in staat om nuwe funksies te skep wat geïsoleer is van die meestertak en dit op ‘n later tydstip te integreer wanneer die funksie gereed is vir integrasie.
As u nie by Git is nie, sal die volgende skakels help om vinnig aan die gang te kom:
Git – Die eenvoudige gids
Basiese beginsels van Git-tak
‘N Suksesvolle Git-takmodel
In Git is daar twee maniere om veranderinge van een tak na ‘n ander te integreer:
Ons sal kyk na samesmelting met die -ff-opsie en die –no-ff-opsie. Opmerking: daar is geen git –no-ff-rebase-opdrag nie.
1 ‘N Vinnige demonstrasie-opstelling
2 Hoe om te gebruik: git merge
3 Hoe om te gebruik: git rebase
4 Smeer of herinvoer?
‘N Vinnige demonstrasie-opstelling
Laat ons eers ‘n werkende Git-bewaarplek opstel met die volgende opdragte voordat ons na die twee maniere van samesmelting van Git kyk:
eggo “foo bar baz” > mycode / foo.txt
git voeg foo.txt by
Laat ons nou ‘n nuwe tak met die naam “myfeature” skep en na dit oorgaan:
1 git check -b myfeature
Nou kan ons ‘n verandering aan die “foo.txt” -lêer in die “myfeature” -tak van ons plaaslike repo maak:
eggo -e “foo bar baznquux” > foo.txt
git commit -a -m ‘myfeature bygevoeg’
Laat ons aanneem dat ons “myfeature” -verandering voltooi is, en ons wil nou graag hierdie funksie in ons “meester” -tak integreer.
Ons git-grafiek sal so lyk:
B my funksie
Soos voorheen oor Git gesê, het ons twee maniere om dit te bewerkstellig: óf ‘n samesmelting óf ‘n herinvoering doen.
Hoe om te gebruik: git merge
Die Git-merge-opdrag verbind twee of meer takke aanmekaar.
Laat ons eers terugkeer na die ‘meester’, sodat ons die samesmelting op ons hoofvertakking kan toepas.
1 git checkout meester
Ons kan nou saamsmelt, maar kom ons bespreek eers die twee verskillende maniere om ‘n samesmelting te bewerkstellig.
Dikwels is die huidige takhoof ‘n voorouer van die genoemde pleeg (‘myfeature’). Dit is die algemeenste geval. In hierdie scenario is ‘n nuwe verbintenis nie nodig om die gekombineerde geskiedenis op te slaan nie. In plaas daarvan word die git HEAD (saam met die indeks) opgedateer om op die genoemde commit te wys sonder om ‘n ekstra merge-commit te skep.
Die standaardgedrag van git merge is om ‘n vinnig-voorwaartse samesmelting te doen, indien moontlik. Hierdie standaardgedrag kan met die -ff-opsie eksplisiet gemaak word, of hierdie gedrag kan onderdruk word met die nie-snel-vorentoe-samesmeltingsopsie (–no-ff). Wanneer ‘n geannoteerde merker saamgevoeg word, skep Git altyd ‘n samesmeltingsverbintenis, selfs al is ‘n voorwaartse samesmelting moontlik.
As u –no-ff gebruik, kan iemand wat die git-geskiedenis hersien, duidelik sien watter tak u nagegaan het om aan te werk. Let ook op hoe die –no-ff-samesmelting ‘n ekstra samesmeltingsverbintenis aan die einde het.
Hieronder is ‘n afbeelding wat die verskil tussen ‘n –no-ff en -ff-samesmelting toon.
Dus het u nou die opsie om een ​​van die volgende te gebruik:
1 Git myfeature saamsmelt
Na hierdie opdrag sal ons git-grafiek so lyk:
1 A – B meester
Of ons kan die takgeskiedenis behou deur dit te doen:
In laasgenoemde geval sou ons git-grafiek nou so lyk:
A – C meester
En as ons die volgende git log-opdrag uitvoer:
1 git log –grafiek – volledige geskiedenis –all –pretty = formaat: “% h% x09% d% x20% s”
Dit sal ‘n soortgelyke git-grafiek toon:
* 5368727 (HOOF, meester) Merge tak ‘myfeature’
| * 6267227 (myfeature) myfeature bygevoeg
* ac54e38 Boodskapboodskap
Watter tipe samesmelting u verkies, hang af van hoeveel van die takinligting u wil stoor wanneer u saamsmelt.
Hoe om te gebruik: git rebase
Die tweede manier om veranderinge van een tak in ‘n ander te integreer, is om ‘n git-rebase uit te voer.
Wanneer samesmelting twee takke bymekaarbring, terwyl u die grafiek van elke begrafnisgeskiedenis behou, verenig u die takke deur die veranderinge van die bronvertakking te herskryf sodat hulle verskyn as kinders van die bestemmingstak.
Die git-rebaseer vooruit-hawens, plaas die plaaslike opwaartse kop. Hervorming is die proses om ‘n tak na ‘n nuwe basisverbintenis te verskuif.
Dit is hoe dit in ‘n git-grafiek lyk. Aanvaar dat die volgende geskiedenis bestaan ​​en die huidige tak is “myfeature”:
D – E – F – G meester
En as ons dit nou doen:
1 git rebase meester
Die resultaat sou wees:
‘N’ B’– C ‘-funksie
D — E — F — G meester
Die “meester” -tak bevat nou die “myfeature” -vertakking by commit “G” sonder om ‘n merge-commit te skep. Dus in plaas daarvan om by die takke aan te sluit met ‘n samesmeltingsverbintenis, integreer die ‘myfeature’-tak weer deur op die top van die meester te bou. Die resultaat is ‘n lineêre geskiedenis wat vir ontwikkelaars makliker kan verstaan ​​word. Die git-log sou nou die lineêre geskiedenis van “D — E — F — G-meester” toon.
In geval van konflik, sal git-rebase by die eerste problematiese poging stop en sal konflikmerkers in die boom gelaat word.
Smeer of herinvoer?
Albei metodes van kode-integrasie moet gebruik word wanneer dit die beste geskik is. Daar is verskillende menings oor wanneer ‘n sekere metode gebruik moet word.
Hier is ‘n paar skakels wat situasies beskryf wanneer een metode bo die ander verkies kan word:
saamsmelt of herbasiseer?
Wanneer om saam te smelt teen wanneer om terug te keer
Werkstroom van Git Team: saamsmelt of herformuleer?
Lesse in PHP: Toon foute en fouthantering
Versmelt: webhostingdienste wat prestasie en betroubaarheid saamsmelt met vinnige, kundige ondersteuning vir MKB’s, liefdadigheidsorganisasies en ondernemings