Kaip git susijungia po darbo vyšnių tvoros?

Tarkime, mes turime master filialą.

Tada mes sukuriame naują newbranch

 git checkout -b newbranch 

ir padarykite du naujus įsipareigojimus newbranch : saistību1 ir įsipareigojimui2

Tada eikite į šeimininką ir cherry-pick

 git checkout master git cherry-pick hash_of_commit1 

Žvelgiant į gitk , matome, kad dedikuoti1 ir jos vyšnių versija turi skirtingus maišus, todėl techniškai tai yra dvi skirtingos fiksacijos.

Galiausiai, mes sujungiame newbranch į master :

 git merge newbranch 

ir pažiūrėkite, kad šie du įsipareigojimai su skirtingais maišais buvo sujungti be problemų, nors jie reiškia, kad tie patys pakeitimai turi būti taikomi du kartus, todėl vienas iš jų turi žlugti.

Ar „git“ iš tikrųjų daro protingą pataisymą, kad būtų galima sujungti turinį ir nuspręsti, ar pakeitimai neturėtų būti taikomi dvigubai, ar jie priskiriami bendrai?

125
23 янв. Paulius nustatė sausio 23 d 2013-01-23 20:50 '13, 8:50 pm 2013-01-23 20:50
@ 2 atsakymai

Trumpas atsakymas

Nesijaudinkite, Git jį tvarkys.

Ilgas atsakymas

Skirtingai nuo, pavyzdžiui, SVN 1, „ Git“ neišsaugo fiksuojamų delta formatų, tačiau pagal momentinius vaizdus 2,3 . Nors SVN naiviai bandys taikyti kiekvieną susijungimą kaip pleistrą (ir su klaida, dėl jūsų aprašytos priežasties), „Git“ paprastai gali tvarkyti šį scenarijų.

Sujungus „Git“ bandys sujungti abiejų HEAD momentinius vaizdus į naują momentinę nuotrauką. Jei abiejose nuotraukose kodo arba failo dalis yra identiška (t. Y., Nes įdėjimas jau yra pasirinktas vyšnių), „Git“ jo nepalies.

Šaltiniai

1 Pereiti prie „Deltas“ į „Subversion“
2 „ Git“ pagrindai
3 „ Git“ objekto modelis

87
23 янв. atsakymą pateikė helmbert 2013-01-23 21:08 '13, 21:08 2013-01-23 21:08

Po šio susijungimo galite dvigubai pasirinkti vyšnių istoriją.

Sprendimas užkirsti kelią tai, kad citatau iš straipsnio, kuriame rekomenduojama, kad filialai su dviem egzemplioriais (vyšniomis) įsipareigotų naudoti susijungimą prieš susijungimą:

„git“ sujungimas po git cherry-pick: vengiant pakartotinių įsipareigojimų

Tarkime, mes turime pagrindinį filialą ir filialą b:

  o---X <-- master \ b1---b2---b3---b4 <-- b 

Dabar mums skubiai reikalingi b1 ir b3 įsipareigojimai šeimininke, bet b. Taigi tai, ką mes darome, yra pagrindinio filialo tikrinimas ir b1 ir b3 vyšnių griebimas:

 $ git checkout master $ git cherry-pick "b1 SHA" $ git cherry-pick "b3 SHA" 

Rezultatas:

  o---X---b1'---b3' <-- master \ b1---b2---b3---b4 <-- b 

Tarkime, mes darome kitą įsipareigojimą valdyti, ir mes gauname:

  o---X---b1'---b3'---Y <-- master \ b1---b2---b3---b4 <-- b 

Jei dabar sujungėme b filialą į kapitoną:

 $ git merge b 

Mes gautume:

  o---X---b1'---b3'---Y--- M <-- master \ / b1----b2----b3----b4 <-- b 

Tai reiškia, kad b1 ir b3 įvesti pakeitimai istorijoje bus rodomi du kartus. Jei norite to išvengti, galime įdiegti, o ne sujungti:

 $ git rebase master b 

Kas duos:

  o---X---b1'---b3'---Y <-- master \ b2---b4 <-- b 

Galiausiai:

 $ git checkout master $ git merge b 

suteikia mums:

  o---X---b1'---b3'---Y---b2---b4 <-- master, b 
9
07 июля '17 в 11:50 2017-07-07 11:50 atsakymas pateikiamas ephemerr liepos 07 d. 17 val. 11:50 2017-07-07 11:50

Kiti klausimai apie žymes arba Ask a Question