Выполняется слияние с наличием конфликтов visual studio

Обновлено: 04.07.2024

Создайте архивную папку для хранения старых выпусков, которые уже нет смысла поддерживать. После создания архивной ветви структура папок будет выглядеть примерно так:

Main - главная ветвь сборки.
- Source .
- Другие папки ресурсов.
- Release 2 - ветвь сопровождения.
  - Source .
  - Другие папки ресурсов.
  - Release 1 - архивная ветвь.
    - Source .
    - Другие папки ресурсов.
    Перемещая ветви из папки Releases в архив, вы разгружаете папку Releases и одновременно сохраняете старые выпуски. Это не создание новой ветви, а, скорее, перемещение старой ветви в новую папку.
    
    Как выполнять слияние
    
    Слияние заключается в переносе изменений из одной ветви в другую. Его можно выполнять, используя возможности обозревателя Source Control или команду tf merge . Слияние выполняется по набору изменений, метке, дате или версии. Чтобы приступить к слиянию, щелкните правой кнопкой ветвь в Source Control и выберите команду Merge . Мастер Source Control Merge Wizard поможет выбрать целевую ветвь (в которую будет выполнено слияние).
    
    В зависимости от структуры ветвей изменения можно переносить вверх по иерархии, вниз по иерархии или поперек иерархии. При поперечном слиянии выполняется слияние без основы. Для выполнения последнего вам придется воспользоваться командой tf merge , поскольку слияние без основы в Visual Studio не поддерживается. Слияние без основы позволяет переносить файлы, не имеющих связей по ветви или слиянию. После проведения слияния без основы необходимые связи устанавливаются, и следующие слияния уже будут иметь основу. Вам по-прежнему придется выполнять их из командной строки, однако число конфликтов слияния сократится.
    
    Имейте в виду, что слияние вдоль иерархии - от родительской к дочерней ветви или от дочерней к родительской ветви - завершается с меньшим количеством конфликтов, чем слияние поперек иерархии. Иерархия ветвей основана на родительских и дочерних ветвях и может отличаться от физической структуры, которую вы видите в Source Control . Например:
    
    При объединении одной ветви в другую изменения файла из фиксаций в одной ветви могут конфликтовать с изменениями в другой. Git пытается разрешить эти изменения с помощью журнала в репозитории, чтобы определить, как должны выглядеть объединенные файлы. Если не ясно, как объединять изменения, Git останавливает слияние и сообщает, какие файлы конфликтуют.
    
    Из этого руководства вы узнаете, как выполнить следующие задачи:
    - Общие сведения о конфликтах слияния
    - Разрешение конфликтов слияния
    Общие сведения о конфликтах слияния
    
    На следующем рисунке показан самый простой пример конфликта изменений в Git. Обе ветви Main и бугфикс обновляют одни и те же строки исходного кода.
    
    Если вы попытаетесь объединить ветвь бугфикс в Main, Git не сможет определить, какие изменения следует использовать в объединенной версии. Вам может потребоваться внести изменения в главную ветвь, ветвь бугфикс или некоторое сочетание этих двух параметров. Устраните этот конфликт с фиксацией слияния в основной ветви, которая согласовывает конфликтующие изменения между двумя ветвями.
    
    Наиболее распространенной ситуацией конфликта слияния является случай, когда вы извлекаете обновления из удаленной ветви в локальную ветвь, например из origin/bugfix в локальную bugfix ветвь. Разрешите эти конфликты аналогичным образом — создайте фиксацию слияния в локальной ветви, чтобы согласовать изменения и завершить слияние.
    
    Что делает Git для предотвращения конфликтов слияния?
    
    Git хранит весь журнал всех изменений, внесенных в репозиторий. Git использует этот журнал, а также отношения между фиксациями, чтобы определить, может ли он упорядочить изменения и автоматически разрешить слияние. Конфликты возникают, только если не ясно, как изменения в одних и тех же строках в одних и тех же файлах должны быть объединены.
    
    Предотвращение конфликтов слияния
    
    Git очень хорошо работает при автоматическом слиянии изменений файлов в большинстве случаев при условии, что содержимое файла незначительно изменяется между фиксациями. Рекомендуется передвинуть ветви перед открытием запроса на вытягивание , если ваша ветвь находится далеко за основной ветвью. Ребазовые ветви будут объединяться в основную ветвь без конфликтов.
    
    Разрешение конфликтов слияния
    
    Если вы используете Visual Studio 2019 версии 16.8 или выше, опробуйте систему управления версиями Git. Узнайте, чем интерфейс Git отличается от Team Explorer, на странице наглядного сравнения.
    
    Вы будете уведомлены о конфликтах слияния при вытягивание изменений или попытке объединить две ветви.
    
    Появится уведомление о конфликте. Щелкните ссылку " конфликты ", чтобы начать устранение конфликтов файлов.
    
    Будет приведен список файлов с конфликтами. Выбор файла позволяет принять изменения в исходной ветви, из которой выполняется слияние, с помощью кнопки взять источник или принять изменения в ветви, в которую выполняется слияние, с помощью команды " оставить цель". Можно выполнить слияние изменений вручную, выбрав объединить, а затем введя изменения непосредственно в средство слияния, указанное в параметрах Git.
    
    Используйте флажки рядом со строками, измененными для выбора между удаленными и локальными изменениями, или измените результаты непосредственно в редакторе результатов в исходном и целевом редакторе в представлении diff.
    
    По завершении внесения изменений нажмите кнопку принять слияние . Повторите это действие для всех конфликтующих файлов.
    
    Откройте представление изменения в Team Explorer и зафиксируйте изменения, чтобы создать фиксацию слияния и разрешить конфликт.
    
    сравните конфликтующие фиксации, а также различия между общим журналом с параметрами в средстве слияния Visual Studio.
    
    Разрешение конфликтов слияния в командной строке:
    
    Используемых Перед выполнением любого pull или убедитесь merge , что репозиторий является чистым с помощью git status .
    
    Выполните pull или merge . Используйте git status , чтобы точно определить, какие файлы не были правильно объединены.
    
    Используемых Проверьте журналы фиксации, чтобы найти фиксации, которые конфликтуют с вашим собственным с помощью git log --merge .
    
    Обновите конфликтующие файлы, перечисленные в git status . Git добавляет маркеры в файлы с конфликтами. Эти маркеры выглядят следующим образом:
    
    <<<<<<< Раздел является изменениями из одной фиксации, ======= отделяет изменения и >>>>>>> для другой конфликтующей фиксации.
    
    Измените файлы так, чтобы они точно проглядели, как они должны удалять маркеры. Используйте git add для размещения разрешенных изменений.
    
    Разрешение конфликтов при удалении файлов с помощью git add (сохранения файла) или git rm (удаление файла).
    
    Если выполняется слияние (например, в pull ), зафиксируйте изменения. Если выполняется переоснование, используйте git rebase --continue для продолжения.
    
    Эта ссылка показывает, как разрешить конфликты Git, но у меня нет ничего в VS, показывающего какие-либо конфликты. Предупреждение о конфликте отображается на веб-сайте VSTS. Каков следующий шаг?
    
    3 ответа
    
    Я использую Visual Studio 2015 Pro и работаю с Git repo. Допустим, я сделал рывок или применил спрятанные изменения или сделал что-то, что привело к конфликту в моей ветви. Например, в этом случае я просто применил тайник: Как вы можете видеть, у меня есть куча изменений, но Web.config находится в.
    
    Обратитесь к этим шагам для разрешения конфликтов:
    
    Чтобы увидеть разницу между двумя ветвями локально (и иметь возможность разрешить конфликт локально), попробуйте сначала выполнить выборку: это приведет к выборке всех ветвей и обновлению их истории.
    
    Затем вы можете попробовать локальное слияние, чтобы увидеть и разрешить конфликты: см. раздел "разрешить конфликты слияния". Если вы можете, перебазируйте свою ветвь поверх обновленной целевой ветви локально, а затем принудительно нажмите (Если вы единственный, кто работает над указанной ветвью): это обновит запрос pull.
    Если нет, объедините целевую ветвь с вашей ветвью и разрешите конфликты локально. Тогда простого нажатия фиксации(коммита) слияния будет достаточно.
    
    Просто чтобы добавить еще несколько мер предосторожности, которые необходимо принять во время разрешения конфликтов в Pull Request.
    
    Убедитесь, что ваша целевая ветвь правильна. Вы выбрали что-то другое неосознанно(иногда случается, что вы знаете, какую ветвь вы хотите объединить, но выбрали мастера из-за ежедневной привычки).
    
    Я сливался, пытаясь разрешить свой конфликт в Visual Studio, извлекая, вытягивая тему и целевую ветвь, а затем слил свою ветвь темы с целевой ветвью : если не видел никакого конфликта в Visual Studio.
    
    Но запрос тяги говорил о разрешении конфликтов.
    
    После 10-15 минтов я понял, что моя целевая ветвь была неправильной.
    
    Это может быть и в вашем случае, я надеюсь, что этого не произойдет. Jusr делится своим опытом и знаниями.
    
    Цель: выполнить пользовательское действие после публикации проекта базы данных сервера SQL в visual studio 2017 Проблема: у меня есть проект базы данных SQL Server (. sqlproj) в решении. Чтобы выполнить действие клиента после публикации проекта, файл .sqlproj изменяется путем добавления нового.
    
    Я клонировал ветвь из ветви разработки и внес в нее некоторые изменения, а затем поднял запрос pull, но в BitBucket у меня есть следующая ошибка Конфликта: изменение источника, изменение целевого Этот файл находится в конфликтном состоянии. Вам нужно будет разрешить конфликт вручную, прежде чем вы.
    
    Похожие вопросы:
    
    Это уже давно не дает мне покоя - Как правильно разрешить конфликт слияния в свойствах SVN, установленных в каталоге? Скажем, например, есть два разработчика, работающие над проектом, где svn:ignore.
    
    В Xcode, как лучше всего избежать конфликта Git в файле проекта? (Я нахожусь в руководстве git, а не использую интерфейс Xcode для git) Я клонировал mapbox-ios-sdk из Github, взломал его, и теперь.
    
    Я использую Microsoft Visual Studio Community 2015 (Версия 14.0.23107.0) и Visual Studio Online с Git. Когда я щелкаю правой кнопкой мыши на файле в Solution Explorer и выбираю сравнить с.
    
    Я использую Visual Studio 2015 Pro и работаю с Git repo. Допустим, я сделал рывок или применил спрятанные изменения или сделал что-то, что привело к конфликту в моей ветви. Например, в этом случае я.
    
    Цель: выполнить пользовательское действие после публикации проекта базы данных сервера SQL в visual studio 2017 Проблема: у меня есть проект базы данных SQL Server (. sqlproj) в решении. Чтобы.
    
    Я клонировал ветвь из ветви разработки и внес в нее некоторые изменения, а затем поднял запрос pull, но в BitBucket у меня есть следующая ошибка Конфликта: изменение источника, изменение целевого.
    
    Использование команды git stash pop Я получил в качестве вывода Автоматическое слияние src/path/File.Java CONFLICT (content): конфликт слияния в src/path/File.Java Решился src/path/File.Java с.
    
    Ранее я объединял ветвь в главную ветвь, используя git bash. Когда произошел конфликт, я могу увидеть и разрешить конфликт в visual studio. Но теперь, не знаю, что случилось, git bash не показывает.
    
    Я и моя команда столкнулись с проблемой синхронизации с visual Studio 2015. Мы используем репозиторий Git с VSTS. Кто-то работал в ветке master, и нам нужно объединить dev и master, но любой, кто.
    
    Системы контроля версий предназначены для управления дополнениями, вносимыми в проект множеством распределенных авторов (обычно разработчиков). Иногда один и тот же контент могут редактировать сразу несколько разработчиков. Если разработчик A попытается изменить код, который редактирует разработчик B, может произойти конфликт. Для предотвращения конфликтов разработчики работают в отдельных изолированных ветках. Основная задача команды git merge заключается в слиянии отдельных веток и разрешении любых конфликтующих правок.
    
    Общие сведения о конфликтах слияния
    
    Слияние и конфликты являются неотъемлемой частью работы с Git. В других инструментах управления версиями, например SVN, работа с конфликтами может быть дорогой и времязатратной. Git позволяет выполнять слияния очень просто. В большинстве случаев Git самостоятельно решает, как автоматически интегрировать новые изменения.
    
    Обычно конфликты возникают, когда два человека изменяют одни и те же строки в файле или один разработчик удаляет файл, который в это время изменяет другой разработчик. В таких случаях Git не может автоматически определить, какое изменение является правильным. Конфликты затрагивают только того разработчика, который выполняет слияние, остальная часть команды о конфликте не знает. Git помечает файл как конфликтующий и останавливает процесс слияния. В этом случае ответственность за разрешение конфликта несут разработчики.
    
    Типы конфликтов слияния
    
    Конфликт во время слияния может произойти в двух отдельных точках — при запуске и во время процесса слияния. Далее рассмотрим, как разрешать каждый из этих конфликтных сценариев.
    
    Git прерывает работу в самом начале слияния
    
    Git прерывает работу во время слияния
    
    Создание конфликта слияния
    
    Чтобы лучше разобраться в конфликтах слияния, в следующем разделе мы смоделируем конфликт для дальнейшего изучения и разрешения. Для запуска моделируемого примера будет использоваться интерфейс Git c Unix-подобной командной строкой.
    
    С помощью приведенной в этом примере последовательности команд выполняются следующие действия.
    - Создается новый каталог с именем git-merge-test , выполняется переход в этот каталог и инициализация его как нового репозитория Git.
    - Создается новый текстовый файл merge.txt с некоторым содержимым.
    - В репозиторий добавляется файл merge.txt и выполняется коммит.
    Теперь у нас есть новый репозиторий с одной веткой main и непустым файлом merge.txt . Далее создадим новую ветку, которая будет использоваться как конфликтующая при слиянии.
    
    Представленная выше последовательность команд выполняет следующие действия.
    - Создает новую ветку с именем new_branch_to_merge_later и выполняет переход в нее.
    - Перезаписывает содержимое файла merge.txt .
    - Выполняет коммит нового содержимого.
    В этой новой ветке new_branch_to_merge_later мы создали коммит, который переопределил содержимое файла merge.txt .
    
    Эта последовательность команд выполняет переключение на ветку main , добавляет содержимое в файл merge.txt и делает коммит. После этого в нашем экспериментальном репозитории находятся два новых коммита, первый — в ветке main , а второй — в ветке new_branch_to_merge_later . Теперь запустим команду git merge new_branch_to_merge_later и посмотрим, что из этого выйдет!
    
    БАХ! 💥 Возник конфликт. Хорошо, что система Git сообщила нам об этом.
    
    Выявление конфликтов слияния
    
    Вывод команды git status говорит о том, что из-за конфликта не удалось слить пути. Теперь файл merge.text отображается как измененный. Давайте изучим этот файл и посмотрим, что изменилось.
    
    Для просмотра содержимого файла merge.txt воспользуемся командой cat . Видно, что в файле появились новые странные дополнения:
    
    Эти новые строки можно рассматривать как «разделители конфликта». Строка ======= является «центром» конфликта. Все содержимое между этим центром и строкой находится в текущей ветке main, на которую ссылается указатель HEAD . А все содержимое между центром и строкой >>>>>>> new_branch_to_merge_later является содержимым ветки для слияния.
    
    Разрешение конфликтов слияния с помощью командной строки
    
    Самый простой способ разрешить конфликт — отредактировать конфликтующий файл. Откройте файл merge.txt в привычном редакторе. В нашем примере просто удалим все разделители конфликта. Измененное содержимое файла merge.txt будет выглядеть следующим образом:
    
    После редактирования файла выполните команду git add merge.txt , чтобы добавить новое объединенное содержимое в раздел проиндексированных файлов. Для завершения слияния создайте новый коммит, выполнив следующую команду:
    
    Git обнаружит, что конфликт разрешен, и создаст новый коммит слияния для завершения процедуры слияния.
    
    Команды Git, с помощью которых можно разрешить конфликты слияния
    
    Общие инструменты
    
    Команда status часто используется во время работы с Git и помогает идентифицировать конфликтующие во время слияния файлы.
    
    При передаче аргумента --merge для команды git log будет создан журнал со списком конфликтов коммитов между ветками, для которых выполняется слияние.
    
    Команда diff помогает найти различия между состояниями репозитория/файлов. Она полезна для выявления и предупреждения конфликтов слияния.
    
    Инструменты для случаев, когда Git прерывает работу в самом начале слияния
    
    Команда checkout может использоваться для отмены изменений в файлах или для изменения веток.
    
    Команда reset может использоваться для отмены изменений в рабочем каталоге или в разделе проиндексированных файлов.
    
    Инструменты для случаев, когда конфликты Git возникают во время слияния
    
    При выполнении команды git merge с опцией --abort процесс слияния будет прерван, а ветка вернется к состоянию, в котором она находилась до начала слияния.
    
    Команду git reset можно использовать для разрешения конфликтов, возникающих во время выполнения слияния, чтобы восстановить заведомо удовлетворительное состояние конфликтующих файлов.
    
    Резюме
    
    Конфликты слияния могут пугать. К счастью, Git предлагает мощные инструменты их поиска и разрешения. Большую часть слияний система Git способна обрабатывать самостоятельно с помощью функций автоматического слияния. Конфликт возникает, когда в двух ветках была изменена одна и та же строка в файле или когда некий файл удален в одной ветке и отредактирован в другой. Как правило, конфликты возникают при работе в команде.
    
    Существует множество способов разрешения конфликтов слияния. В этой статье мы рассмотрели немалое количество инструментов командной строки, которые предоставляет Git. Более подробную информацию об этих инструментах см. на отдельных страницах для команд git log , git reset , git status , git checkout и git reset . Помимо этого многие сторонние инструменты также предлагают оптимизированные функции, поддерживающие работу с конфликтами слияния.
    
    В текущей версии GitHub для Windows, мы сделали небольшое изменение, которое имеет едва заметный эффект, который вы, вероятно, уже заметили. Мы изменили подход к слиянию *.csproj и похожих файлов, используемый по умолчанию.
    Если вы измените .csproj файл в ветке и затем объедините ее с другой веткой, то вы возможно столкнетесь с большим количеством конфликтов слияния, нежели вы могли иметь раньше.
    
    Почему?
    
    Чтож, раньше мы бы использовали union для слияния *.csproj файлов.
    git merge-file документация описывающая эту функцию:
    
    Вместо того, чтоб оставить конфликт в файле, разрешать конфликты в пользу нашей (или их или обоих) стороны.
    
    В общем когда происходит конфликт, система пытается решить эту проблему, стараясь применить все изменения.
    В принципе, это компромисс. Этот подход можно настроить в файле .gitattributes , поэтому если вы действительно хотите использовать такое поведение для своего репозитория, добавьте следующее:
    
    А теперь давайте я расскажу, почему возможно вы не захотите это делать, и почему мы в итоге изменили это.
    
    Слияние объединением обернулось катастрофой
    
    Допустим мы начнем со следующего упрощенного foo.csproj файла в нашей ветке master вкупе файлом .gitattributes :
    
    После создания этого файла давайте убедимся, что мы закоммитили его
    
    Затем мы создаем ветку ( git checkout -b branch ) под оригинальным названием «branch» и вставляем указанный ниже кусок в foo.csproj между элементами AAA.cs и DDD.cs .
    
    Для тех у кого слабенькое воображение, ниже указан результат того, что мы закоммитим в эту ветку.
    
    Не забудьте закоммитить это, если действуете по порядку.
    
    Теперь давайте вернемся обратно в ветку master
    
    И добавим туда же следующий кусок:
    
    В итоге ветка master должна содержать следующее:
    
    И все это закоммитим:
    
    Вы всё еще здесь?
    Хорошо, теперь давайте сольем нашу ветку branch в ветку master
    
    В результате использования слияния объединением мы получим следующее:
    
    Блин(иууу), получилось не совсем то, что мы хотели. Заметьте, что “BBB.cs” встроилось в “CCC.cs” и у нас больше нет закрывающего тэга . Это мягко говоря ужасно.
    При отсутствии файла .gitattributes в репозитории и использовании стандартного подхода слияния, стандартная команда слияния привела к конфликту слияния, который требует исправления. В нашем понимании это лучше, чем не бросающаяся в глаза ошибка, которая останется в вашем проекте.
    
    Очевидно, что в какой-нибудь идеальной параллельной вселенной git поместил бы весь элемент «ссс» после элемента «bbb» без отсебятины и не беспокоя нас по поводу решения этих противных конфликтов слияния. Мы не живем в этой вселенной, но быть может наша может стать чуть более похожей на идеальную. Я слышал там круто.
    
    Что должно быть сделано в Visual Studio?
    
    Я недавно попросил подписчиков в Твитере проголосовать за вопрос запрос к команде Visual Studio о добавлении поддержки шаблонов файлов в проектных файлах. MSBuild уже поддерживает символы-джокеры в файлах .csproj, но у Visual Studio пока с ними не все в порядке.
    
    Уменьшение мучений при решении конфликтов слияния является одной из основных причин сделать это. Если я смогу использовать символ-джокер для указания директории, мне не нужно будет добавлять записи в *.csproj каждый раз, когда я добавляю файл в проект.
    
    С другой стороны, можно написать качественный драйвер слияния XML для Git, но это достаточно серьезное испытание, и мой коллега Marcus Olsson может это подтвердить. Если бы это было просто, или даже сложно но в меру, это было бы уже сделано. Любопытно, если мы ограничим это до обычной проблемы .csproj файлов, сможем ли мы сказать, что хоть это и не отличное, но достаточно хорошее решение для контроля обычных конфликтов слияния? Возможно.
    
    Даже если мы напишем этот драйвер слияния, он сможет решить проблему только одной конкретной системы контроля версии, которая только и важна для нас. :trollface:
    
    Было предположение, что если Visual Studio сначала отсортирует эти элементы, то это может помочь частично решить проблему. Это поможет уменьшить несущественные конфликты возникшие по вине условно недетерминированной сортировки элементов в Visual Studio. Но это не решит проблему слияния как таковую. В примере, который я представил, каждый элемент сохраняет сортировку на протяжении всего примера. Получается, что каждый раз когда в двух разных ветках добавляются файлы смежные файлы, вы рискуете получить конфликт. Что и происходит достаточно часто.
    
    Поддержка символов-джокеров может почти полностью решить эту проблему. Заметьте, я сказал почти. В этом файле время от времени все же будут возникать конфликты, но это будет происходить очень редко.
    
    Читайте также: