[Перевод] Конфликты при слиянии csproj файлов
В текущей версии GitHub для Windows, мы сделали небольшое изменение, которое имеет едва заметный эффект, который вы, вероятно, уже заметили. Мы изменили подход к слиянию *.csproj и похожих файлов, используемый по умолчанию.Если вы измените .csproj файл в ветке и затем объедините ее с другой веткой, то вы возможно столкнетесь с большим количеством конфликтов слияния, нежели вы могли иметь раньше.
Почему? Чтож, раньше мы бы использовали union для слияния *.csproj файлов.git merge-file документация описывающая эту функцию:
Вместо того, чтоб оставить конфликт в файле, разрешать конфликты в пользу нашей (или их или обоих) стороны.
В общем когда происходит конфликт, система пытается решить эту проблему, стараясь применить все изменения.В принципе, это компромисс. Этот подход можно настроить в файле .gitattributes, поэтому если вы действительно хотите использовать такое поведение для своего репозитория, добавьте следующее:
*.csproj merge=union
А теперь давайте я расскажу, почему возможно вы не захотите это делать, и почему мы в итоге изменили это.Слияние объединением обернулось катастрофой
Допустим мы начнем со следующего упрощенного foo.csproj файла в нашей ветке master вкупе файлом .gitattributes:
git init . git add -A git commit -m «Initial commit of gittattributes and foo.csproj» Затем мы создаем ветку (git checkout -b branch) под оригинальным названием «branch» и вставляем указанный ниже кусок в foo.csproj между элементами AAA.cs и DDD.cs.
git commit -a «Add BBB.cs element» Теперь давайте вернемся обратно в ветку master
git checkout master И добавим туда же следующий кусок:
git commit -a «Add CCC.cs element» Вы всё еще здесь? Хорошо, теперь давайте сольем нашу ветку branch в ветку master
git merge branch В результате использования слияния объединением мы получим следующее:
Что должно быть сделано в Visual Studio? Я недавно попросил подписчиков в Твитере проголосовать за вопрос запрос к команде Visual Studio о добавлении поддержки шаблонов файлов в проектных файлах. MSBuild уже поддерживает символы-джокеры в файлах .csproj, но у Visual Studio пока с ними не все в порядке.Уменьшение мучений при решении конфликтов слияния является одной из основных причин сделать это. Если я смогу использовать символ-джокер для указания директории, мне не нужно будет добавлять записи в *.csproj каждый раз, когда я добавляю файл в проект.
С другой стороны, можно написать качественный драйвер слияния XML для Git, но это достаточно серьезное испытание, и мой коллега Marcus Olsson может это подтвердить. Если бы это было просто, или даже сложно, но в меру, это было бы уже сделано. Любопытно, если мы ограничим это до обычной проблемы .csproj файлов, сможем ли мы сказать, что хоть это и не отличное, но достаточно хорошее решение для контроля обычных конфликтов слияния? Возможно.
Даже если мы напишем этот драйвер слияния, он сможет решить проблему только одной конкретной системы контроля версии, которая только и важна для нас. : trollface:
Было предположение, что если Visual Studio сначала отсортирует эти элементы, то это может помочь частично решить проблему. Это поможет уменьшить несущественные конфликты возникшие по вине условно недетерминированной сортировки элементов в Visual Studio. Но это не решит проблему слияния как таковую. В примере, который я представил, каждый элемент сохраняет сортировку на протяжении всего примера. Получается, что каждый раз когда в двух разных ветках добавляются файлы смежные файлы, вы рискуете получить конфликт. Что и происходит достаточно часто.
Поддержка символов-джокеров может почти полностью решить эту проблему. Заметьте, я сказал почти. В этом файле время от времени все же будут возникать конфликты, но это будет происходить очень редко.
p.s.Волею судем наткнулся на эту статью, решил что Вам тоже будет интересно знать, лично я сталкиваюсь с этим постоянно.Это мой первый перевод поэтому пожалуйста ответьте на вопрос в опроснике, хотелось бы знать стоит дальше тратить ваше/мое время или нет.
