Този конкретен конфликтен стил показва само две части от конфликта — но всъщност има три части, просто едната обикновено трябва да бъде изхвърлена.
Не забравяйте, че има "базова" версия на файла и две версии с съвети. Базовата версия е това, с което вие започнахте, преди да направите вашите промени на master—и той започна със същото базова версия, преди той да направи своите промени. Това прави основната версия „основната“: и двамата сте имали един и същ файл, в същата форма, в миналото.
Оттогава – от тази обща база – Git разглежда това като „вие сте направили известен брой ангажименти (поне 1, може би много) и той е направил някои ангажименти (поне един, може би много)“:
o--o--A <-- you (master)
/
...--o--*
\
o--o--o--B <-- him
За да комбинира тези промени, Git изпълнява разлика от * (базата) до A (вашето master) и втора разлика от * до B (неговото garbage, което обикновено наричате origin/garbage вместо това). Git откри някакъв конфликт между „какво направи ти“ и „какво направи той“ и постави това в комбинирания (предимно завършен) файл, използвайки маркерите за конфликт:
[there might be stuff up here too]
<<<<<<<<<<< HEAD
//a bunch of code
=========
>>>>>>>>>>> A bunch of numbers (I'm assuming the hash of the new branch)
//code that I didn't write
//the rest of the code
Това е най-доброто предположение на Git за крайната форма на файла, разрешавайки частите, които не са в конфликт, като същевременно оставя частите, които са в конфликт, там като двата набора от код. Липсва една голяма част: с какво според Git започнахте и двамата?
Да кажем, например, че Git погрешно е решил, че и двамата сте запазили 17-ия напълно празен ред, защото вашият нов файл има празен ред близо до него, а неговият нов файл има празен ред близо до него (въпреки че всъщност това е само < em>случайно съвпадение). След това Git успя да реши, че всичко, което направи след този празен ред, не е в конфликт, така че това е във вашия комбиниран файл, но не е маркирано с маркер за конфликт.
Междувременно Git реши, че поради този "запазен" празен ред, вие сте добавили първия раздел // a bunch of code, но той не го е направил. (Това може действително да е било в оригиналния файл, но когато Git се синхронизира неправилно, той се оказва „изглежда нов“. Или може наистина да е изцяло нов.)
След тази част, между първоначалните <<< шеврони и === реда, Git включва кода, който смята, че той е добавил: това е всичко след === реда, до >>> реда. (В този случай той смята, че не е добавил нищо тук: вероятно смята, че е изтрил нещо, като например празен ред.)
Останалата част от кода, включително // code that [you] didn't write, или вече беше в основата, или Git успя да добави, без да види конфликт.
Смятам, че е по-добре да задам merge.conflictstyle на diff3. Това променя начина, по който Git вмъква двата конфликтни раздела в най-вече финалния файл: той поставя частта, която може да обработи сам, след това маркера <<<<<<<, след това това, което смята, че сте добавили, ако има нещо, след това поредица от вертикални ленти |||||||, след това основният код, който Git смята, че трябва да бъде заменен, след това маркерът =======, след това неговият код, след това затварящият маркер >>>>>>>.
Git смята, че е вероятно да се отървете от основния код и да използвате един или друг от HEAD или други секции с код на клон или може би дори комбинация от HEAD и други. Но ако секцията база се окаже пълна глупост, можете веднага да разберете, че Git е синхронизирал нещо фалшиво, като празни редове и редове, състоящи се само от }, например.
person
torek
schedule
12.11.2016
