Конфликт при слиянии двух ветвей с git

Question

У меня проблема с объединением двух ветвей. У меня есть XML-файл со следующим содержанием:

<?xml version="1.0" encoding="utf-8"?> 
<language xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="sk" xsi:noNamespaceSchemaLocation="language.xsd"> 
    <topic name="topicName"> 
    <section name="sectionName"> 
     <pair key="key_1" state="0">value 1</pair> 
     <pair key="key_2" state="0">value 2</pair> 
    </section> 
    </topic> 
</language> 

Тогда следующий случай:

Филиал «мастер» изменения в XML-файле только «состояние» от «0» до «1». т.е.

<?xml version="1.0" encoding="utf-8"?> 
<language xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="sk" xsi:noNamespaceSchemaLocation="language.xsd"> 
    <topic name="topicName"> 
    <section name="sectionName"> 
     <pair key="key_1" state="1">value 1</pair> 
     <pair key="key_2" state="1">value 2</pair> 
    </section> 
    </topic> 
</language> 

Изменения, которые были внесены, были отправлены в теневой репозиторий.

Ветвь «Тест» добавляет новый узел. то есть:

<?xml version="1.0" encoding="utf-8"?> 
<language xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="sk" xsi:noNamespaceSchemaLocation="language.xsd"> 
    <topic name="topicName"> 
    <section name="sectionName"> 
     <pair key="key_1" state="0">value 1</pair> 
     <pair key="key_2" state="0">value 2</pair> 
     <pair key="key_3" state="0">value 3</pair> 
    </section> 
    </topic> 
</language> 

изменения, которые были внесены, и отправлены в центральный хранилище.

Когда я сливаю ветку «Тест» на ветке «мастер», я получаю конфликт. т.е.

[master] git pull origin Test 

Конфликтующее файл выглядит следующим образом:

<?xml version="1.0" encoding="utf-8"?> 
<language xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="sk" xsi:noNamespaceSchemaLocation="language.xsd"> 
    <topic name="topicName"> 
    <section name="sectionName"> 
<<<<<<< HEAD 
     <pair key="key_1" state="1">value 1</pair> 
     <pair key="key_2" state="1">value 2</pair> 
======= 
     <pair key="key_1" state="0">value 1</pair> 
     <pair key="key_2" state="0">value 2</pair> 
     <pair key="key_3" state="0">value 3</pair> 
>>>>>>> b872e7d1bbbe281482baefa73e322a34c475aa92 
    </section> 
    </topic> 
</language> 

Я не понимаю, почему такого рода изменения приводят к конфликтам. Я могу заверить, что в файлах нет других изменений, таких как пробелы, вкладки или новые строки. (Я неоднократно воспроизводил этот конфликт)

Когда я открываю конфликтный файл с помощью инструмента слияния, он не конфликтует. Он показывает только изменения, и инструмент слияния не автоматически объединяет новую строку. (Я использую git version 1.7.10.4)

Может кто-нибудь объяснить, почему это происходит, и как я могу избежать подобных конфликтов.

Заранее благодарен.

EDIT: Я искал лучшие инструменты для слияния для разрешения git-конфликтов. Я нашел kdiff3. Когда я сделал команду:

git mergetool --tool kdiff3 sk.xml 

инструмент не показывал, но он автоматически разрешен конфликт. Я был очень счастливым.

Теперь мои вопросы:
1. Почему не может это сделать?
2. Может ли «kdiff3» доверять, что он решил конфликт хорошо? Я проверил вручную этот тип конфликта, который я опубликовал, и он решил конфликт хорошо. Но возможно ли, что этот инструмент может объединить файлы автоматически неправедно?

Answer 1

Две линии были изменены как на главном, так и на тестовом ветви. Это типичный случай для конфликта слияния.

Git не может знать, если это состояние для ключей 1 и 2 теперь должно быть 1 (как указано на главном) или 0 (как и в тесте). Мы должны решить это вручную.

Answer 2

В то время как мы, люди, признаем, что 1-я ветвь только что сменила символ 0 на каждой из двух линий до 1, большинство инструментов diff/merge не видят этого.Эти программы ориентированы по строкам.
2 линии были удалены. В нее были вставлены две новые линии. Любое сходство не имеет значения.

Вторая ветвь вставляет другую линию, но где? Мы знаем, что это до линии </section>, но две строки перед этим приводятся для удаления другой веткой. Единственное, что то же самое, это линия <section ... >.

У человека было бы разумно предположить, что новая key_3 линия должна быть вставлена ​​после двух новых key_1 & key_2 линий, но нет никакого разумного способа быть programmaticly уверен.

Erring на стороне осторожности не является необоснованным.

Чтобы избежать этого, потребуются инструменты для сравнения бит/символов, но для этого есть и цены.