Конфликты слияния в Git
Системы контроля версий предназначены для управления дополнениями, вносимыми в проект множеством распределенных авторов (обычно разработчиков). Иногда один и тот же контент могут редактировать сразу несколько разработчиков. Если разработчик A попытается изменить код, который редактирует разработчик B, может произойти конфликт. Для предотвращения конфликтов разработчики работают в отдельных изолированных ветках. Основная задача команды git merge заключается в слиянии отдельных веток и разрешении любых конфликтующих правок.
Общие сведения о конфликтах слияния
Слияние и конфликты являются неотъемлемой частью работы с Git. В других инструментах управления версиями, например SVN, работа с конфликтами может быть дорогой и времязатратной. Git позволяет выполнять слияния очень просто. В большинстве случаев Git самостоятельно решает, как автоматически интегрировать новые изменения.
Обычно конфликты возникают, когда два человека изменяют одни и те же строки в файле или один разработчик удаляет файл, который в это время изменяет другой разработчик. В таких случаях Git не может автоматически определить, какое изменение является правильным. Конфликты затрагивают только того разработчика, который выполняет слияние, остальная часть команды о конфликте не знает. Git помечает файл как конфликтующий и останавливает процесс слияния. В этом случае ответственность за разрешение конфликта несут разработчики.
Типы конфликтов слияния
Конфликт во время слияния может произойти в двух отдельных точках — при запуске и во время процесса слияния. Далее рассмотрим, как разрешать каждый из этих конфликтных сценариев.
Git прерывает работу в самом начале слияния
Git прерывает работу во время слияния
Сбой В ПРОЦЕССЕ слияния говорит о наличии конфликта между текущей локальной веткой и веткой, с которой выполняется слияние. Это свидетельствует о конфликте с кодом другого разработчика. Git сделает все возможное, чтобы объединить файлы, но оставит конфликтующие участки, чтобы вы разрешили их вручную. При сбое во время выполнения слияния выдается следующее сообщение об ошибке:
Создание конфликта слияния
Чтобы лучше разобраться в конфликтах слияния, в следующем разделе мы смоделируем конфликт для дальнейшего изучения и разрешения. Для запуска моделируемого примера будет использоваться интерфейс Git c Unix-подобной командной строкой.
С помощью приведенной в этом примере последовательности команд выполняются следующие действия.
Представленная выше последовательность команд выполняет следующие действия.
БАХ! 💥 Возник конфликт. Хорошо, что система Git сообщила нам об этом.
Выявление конфликтов слияния
Вывод команды git status говорит о том, что из-за конфликта не удалось слить пути. Теперь файл merge.text отображается как измененный. Давайте изучим этот файл и посмотрим, что изменилось.
Разрешение конфликтов слияния с помощью командной строки
Самый простой способ разрешить конфликт — отредактировать конфликтующий файл. Откройте файл merge.txt в привычном редакторе. В нашем примере просто удалим все разделители конфликта. Измененное содержимое файла merge.txt будет выглядеть следующим образом:
Git обнаружит, что конфликт разрешен, и создаст новый коммит слияния для завершения процедуры слияния.
Команды Git, с помощью которых можно разрешить конфликты слияния
Общие инструменты
Команда status часто используется во время работы с Git и помогает идентифицировать конфликтующие во время слияния файлы.
Команда diff помогает найти различия между состояниями репозитория/файлов. Она полезна для выявления и предупреждения конфликтов слияния.
Инструменты для случаев, когда Git прерывает работу в самом начале слияния
Команда checkout может использоваться для отмены изменений в файлах или для изменения веток.
Команда reset может использоваться для отмены изменений в рабочем каталоге или в разделе проиндексированных файлов.
Инструменты для случаев, когда конфликты Git возникают во время слияния
Команду git reset можно использовать для разрешения конфликтов, возникающих во время выполнения слияния, чтобы восстановить заведомо удовлетворительное состояние конфликтующих файлов.
Резюме
Конфликты слияния могут пугать. К счастью, Git предлагает мощные инструменты их поиска и разрешения. Большую часть слияний система Git способна обрабатывать самостоятельно с помощью функций автоматического слияния. Конфликт возникает, когда в двух ветках была изменена одна и та же строка в файле или когда некий файл удален в одной ветке и отредактирован в другой. Как правило, конфликты возникают при работе в команде.
Готовы попробовать ветвление?
Ознакомьтесь с этим интерактивным обучающим руководством.
Безболезненное разрешение Merge конфликтов в Git
Предлагаю читателям «Хабрахабра» перевод публикации «Painless Merge Conflict Resolution in Git»
из блога blog.wuwon.id.au.
В моей повседневной работе, часто приходится иметь дело со множеством git ветвей (branch). Это могут быть ветви промежуточных релизов, ветви с устаревшим API находящиеся на поддержке для некоторых клиентов, или ветви с экспериментальными свойствами. Лёгкость создания ветвей в модели Git так и соблазняет разработчиков создавать все больше и больше ветвей, и как правило бремя от большого количества ветвей становится очень ощутимым, когда приходится все эти ветви поддерживать и периодически делать слияния (merge) с другими ветвями.
Слияния очень важны для поддержания кода в актуальном состоянии, и как правило ошибка сделанная при слиянии может привести к большей головной боли, нежели ошибка сделанная при простом коммите. К сожалению ошибки слияния далеко не редкость, потому что во-первых слияния имеют несколько родительских ветвей. Даже при анализе истории слияния ветвей, бывает очень трудно понять, какие же изменения были сделаны для разрешения конфликта. Во-вторых, отмена неудачного слияния может превратиться в большую головную боль. В-третьих, большая часть конфликтов слияния происходит при работе с чужим кодом, потому что само понятие ветвей подразумевает множество пользователей, т.е. далеко не всегда слияние производит тот же человек который работал с той или иной веткой. В сухом остатке, сделать ошибку при слиянии очень легко, её трудно исправить и трудно найти. Таким образом время потраченное на изучение и понимание процесса слияния ветвей, окупится с лихвой.
Удивительно, но я обнаружил, что многие доступные инструменты и интерфейсы предназначенные для выполнения слияний, не достаточно хорошо оснащены для эффективного выполнения этого процесса. Часто программист просто надеется что команда git merge сделает за него всю работу. Но когда все-таки происходит конфликт, то обычно стратегия слияния заключается в беглом просмотре кода вокруг строки конфликта, и интуитивном угадывании что именно данный кусок кода предпочтительней другого.
В данной статье я надеюсь продемонстрировать что процесс разрешения конфликтов может быть пошагово точным, при котором отпадает необходимость что-либо там угадывать.
Голубые Розы (Roses are Blue)
Давайте предположим что вашей команде поручили писать поэмы в отведённом для этих целей репозитории. (Какой кошмар!) А вам доверили самое главное — делать слияния последних фиксов из ветки master в ветку beta. Итак, вы переключаетесь в ветку beta и выполняете следующую команду:
Ого, это конфликт. Вы решаете просмотреть файл на который ссылается git:
Замечательно! Весь файл, как показывает Listing 1, находится в конфликтном состоянии. Какой же вариант файла является более корректным? Оба варианта выглядят корректно. Верхний вариант написан в хакер-стиле с элементами цветовой кодировки в стиле HTML и с использованием только строчных букв. Нижний вариант выглядит более натурально, с использованием пунктуации и заглавных букв.
Если бы это был ваш проект, вы бы могли просто выбрать один вариант и покончить с этим слиянием. Но проблема в том, что это не ваша поэма, вы никогда не читали эту поэму раньше, не были ответственны за написание или редактирование, и вы отлично понимаете что в случае не верного решения чья-то тяжёлая работа может кануть в небытие. Однако вас всё же назначили ответственным по слиянию этих веток. Что же вам делать?
Назад к Базе (Back to Base)
Хитрость заключается в том, что Listing 1 не даёт вам полную информацию, необходимую для совершения корректного слияния. На самом деле, в процессе слияния участвуют четыре важных части информации (состояния), три из которых просто необходимы для успешного разрешения конфликта. В случае Listing 1, Git предоставил вам только два состояния.
Следующая диаграмма иллюстрирует эти четыре состояния:
Состояния (B) и © относятся к текущим положениям (head) веток master и beta соответственно, эти два состояния как раз таки и отражены в Listing 1. Состояние (D) это результат слияния, то что вы хотите получить/сгенерировать в конечном итоге (в большинстве случаев Git автоматически генерирует состояние (D)). Состояние (А) на самом верху, представляет собой базу (основу) слияния веток master и beta. База слияния (A) это последний общий предок веток master и beta, и пока предположим что это база слияния уникальна. Как мы увидим позже состояние (A) играет ключевую роль в разрешении конфликтов. На диаграмме я также отразил дельты 1 и 2, которые представляют изменения между состояниями (A)-(B), и (A)-© соответственно. Зная состояния (A), (B) и © дельты 1 и 2 могут быть легко получены (вычислены). Обратите внимание, что дельты 1 и 2 могут состоять из более чем одного коммита. Но для наших целей будем считать что все дельты монолитны.
Чтобы понять, как получить состояние (D), вы должны понимать что же операция слияния пытается сделать. Состояние (D) должно представлять собой сочетание изменений, внесённых в ветку master и beta соответственно. Т.е. другими словами сочетание дельт 1 и 2. Идея проста на поверхности и большую часть времени не требует вмешательства со стороны человека, за исключением особых случаев когда дельты затрагивают наслаиваемые (пересекающиеся) части файла. В такой ситуации вам требуется помочь машине сгенерировать результат (D), путём сравнения дельт 1 и 2.
Определение Отличий (Identifying the Differences)
Для того чтобы найти изменения внесённые в каждую ветку, необходимо знать как выглядит база слияния, состояние (A). Самый простой механизм получения информации о базе слияния, это установка опции merge.conflictstyle в значение diff3
Теперь мы видим третий фрагмент посередине, который и является базой слияния или состояние (A). Изменения видны как на ладони: в ветке beta (HEAD) человеческие названия цветов были заменены на HTML коды, а в ветку master добавили капитализацию и пунктуацию. Основываясь на этих знаниях, мы теперь знаем что результат должен включать в себя капитализацию, пунктуацию и HTML коды цветов.
В принципе на этом можно было бы и закончить, потому что результат достигнут. Но есть решение и получше.
Графическое Слияние (GUI Merging)
Хотя и простое текстовое представление конфликта слияния делает свою работу в простых случаях, на практике конфликты могут быть более радикальными и сложными. В таких случаях могут помочь графические инструменты. Мой выбор пал на простой инструмент написанный на Python под названием meld, но может подойти любой другой графический инструмент, способный представить слияние в трёх-колоночном виде.
Для использования графического инструмента (он должен быть установлен), после того как git пожаловался что есть конфликт, введите следующую команду:
Последует вопрос какой программой для слияния вы хотели бы воспользоваться, просто введите meld и нажмите Enter. Вот как окно программы может выглядеть (подразумевается опция merge.conflictstyle не была включена):
Несмотря на то что информация представлена бок о бок, она не отображает нужные фрагменты которые были в Listing 2. Мы не видим здесь фрагмента базы слияния (состояния (A)), что мы видим это файл roses.txt.LOCAL.2760.txt в левой колонке и файл roses.txt.REMOTE.2760.txt в правой колонке и файл посередине это неудачное слияние. Т.е. по сути нам представили состояния (B), © и несостоявшееся состояние (D), но состояние (A) отсутствует.
Правда отсутствует? Давайте проверим, в старом добром терминале:
Видим интересующий нас файл: roses.txt.BASE.2760.txt. Это и есть файл базы слияния. Теперь нам осталось всего лишь найти изменения внесённые в ветки master и beta, по отношению к базе. Мы можем сделать это двумя отдельными вызовами meld:
(Кто-то может подметить что было бы более разумно, поменять порядок аргументов в первом вызове, для того чтобы файл базы находился в левой колонке в обоих случаях, но именно такой порядок сохраняет подобие трёх-колоночного вида, при котором база остаётся по середине.) Результат выполнения — два окна как показано ниже:
При чтении первого окна справа налево и второго окна слева направо, становится ясно как день, какие изменения произошли в каждой ветке. Так как meld любезно подсветил все изменения, теперь практически не возможно пропустить даже мелко заметные правки (Кто-нибудь заметил добавление предлога «of» при просмотре текстового представления разрешения конфликта Listing 1 или даже Listing 2?)
Вооружившись этими знаниями, мы теперь можем вернуться к трёх-колоночному представлению и сделать изменения. Моя стратегия ручного слияния это взять весь текст из ветки с более весомыми изменениями (в данном случае master/REMOTE т.е. beta), и поверх него производить пошаговые правки, т.е. вносить изменения сделанные в другой ветке (master). Вот что получилось:
А теперь всё вместе (All Together Now)
И добавьте следующее в ваш
Теперь, когда вы в следующий раз будете запускать команду git mergetool для разрешения конфликта, откроются все три окна:
После того как вы привыкните к такому разрешению конфликтов с использованием трёх вышеупомянутых окон, вы скорее всего обнаружите, что процесс стал более методичным и механическим. В большинстве случаев, вам даже не придётся читать и понимать куски кода из каждой ветки, для того чтобы понять какой же вариант применить для слияния. Вам больше не понадобится догадываться, потому что вы будете гораздо более уверенным в корректности вашего комита. Из-за этой уверенности, появится чувство что разрешение конфликтов превратилось в увлекательное занятие.
Бонус от переводчика
Для тех кто пользуется tmux и n?vim, предлагаю следующий скрипт gitmerge:
Примечание: если вы не используете эту опцию в своем
/.tmux.conf, то вам надо поменять в двух последних строках «$sn:1» на «$sn:0»
Соответственно добавьте следующее в ваш
Воркфлоу разрешения конфликта будет выглядеть так:
Пока игнорируем вопрос (Was the merge successful [y/n]?) и переключаемся в сессию под названием gitmerge (сочетание TMUXPREFIX + s):
Видим наше трёх-оконное представление на одном экране. Цифрами обозначены сплиты (panes) tmux’a, буквами соответствующие состояния. Делаем правки для разрешения конфликта, т.е. редактируем состояние (D) и сохраняем. После этого возвращаемся обратно в исходную сессию tmux’a и подтверждаем что слияние произошло успешно.
git rebase master
Лично я предпочитаю и считаю более правильным делать сначала rebase master в ветке beta, и только после этого переключаться в master и делать git merge beta. В принципе воркфлоу не сильно отличается, за исключением трёх-оконного вида.
Переключаемся в сессию gitmerge
Обратите внимание, что состояния (B) и © поменялись местами:
Рекомендую всем поиграться с примером репозитария хотя бы один раз, сделать разрешение конфликта по вышеописанной схеме. Лично я больше не гадаю а что же выбрать «Accept theirs» или «Accept yours».
How To Resolve Merge Conflicts in Git
Home » DevOps and Development » How To Resolve Merge Conflicts in Git
The git merge command helps a contributor add to a project from a branch. The concept is one of the core ideas of collaborative programming, allowing multiple people to work on their part of the code without any conflicts.
When multiple contributors work on the same part of a code or work with numerous branches, merge conflicts are bound to happen. The primary goal of git merge is to resolve or warn about these conflicts automatically.
This guide explains what a merge conflict is and offers resolutions for when they do not sort out automatically. The article also provides helpful tips for preventing Git merge conflicts.
What Is a Git Merge Conflict?
When working with version control systems such as Git, most merge conflicts resolve automatically. However, there are situations where git merge is unable to resolve an issue.
Some examples of merge conflicts include:
Since the problem happens locally and the rest of the project members are unaware of the issue, resolving the conflict is of high priority and requires an immediate fix.
Types Of Git Merge Conflicts
The general types of merge conflicts depend on when the issue appears. The conflicts happen either:
How To Resolve Merge Conflicts in Git
There are three ways to resolve a merge conflict in Git:
1. Accept the local version. To accept all changes on a file from the local version, run:
Alternatively, to accept the local version for all conflicting files, use:
2. Accept the remote version. To update the changes on a file from the remote branch, run:
Accept the remote version for all conflicting files with:
Ultimately, the choice of what parts of the code stay and which do not depends on the developer’s decision for the current project.
Getting a Merge Conflict in Git
The merge conflict in Git happens when the command git merge throws an error.
The error message prints the information about where the conflict is present. Check the file from the error message and look at the contents where the merge conflict happened:
Git automatically adds three indicators alongside the conflicting lines of code:
The added syntax helps search through the code to find the location of the merge conflict. However, a much more straightforward approach is to use a difference/merging tool to discover the issues and track the changes.
Setting Up a Default Diff Tool in Git
To set up the default diff tool for git mergetool :
1. Run the following line in your terminal:
The output prints out all the supported diff tools for your current setup:
Different tools are available based on the editor of choice. For example:
The further steps show an example of how to set up the vimdiff tool for Vim.
2. Change the git config to set the default merge tool:
For example, if using Vim, run:
3. Set the diff tool to show the common ancestor for both files, which is the version before any edits:
4. Set the option to not prompt before running:
The diff tool setup for Git is complete.
Using Mergetool to See the Differences
To use the mergetool and see the differences, run:
The output displays a window with four views:
1. LOCAL represents the file version from the current branch.
2. BASE is how the file looked before any changes.
3. REMOTE shows how the file looks in the remote branch where the conflicting information is.
4. MERGED has the final merge file. This result represents what gets saved to the repository.
The primary navigation commands between these windows are:
Updating and Resolving a Merge Conflict
Update the MERGED file to resolve a conflict. Some shortcuts for updating the MERGED version include:
Note: Ensure the cursor is on the line where the conflicts are before running these commands.
Commit and Cleanup
The final step is to commit and clean up the extra files. Commit the updated version by running:
Note: If you made a mistake while committing, you could undo the last commit.
The diff tool creates extra files on the project for comparing versions. Clean them up with:
Tips On How to Prevent Merge Conflicts
Merge conflicts only happen when the computer is not able to resolve the problem automatically.
Here are some tips on how to prevent merge conflicts:
Merge conflicts happen when working in Git or other version control programs from time to time. By following the instructions in this guide, you know how to handle merge conflicts and how to prevent them from happening.
For more Git resources, check out our article on What Is Git Upstream and How To Set Upstream Branch.
Как разрешать конфликты слияния в Git
есть ли хороший способ объяснить, как разрешить конфликты слияния в Git?
30 ответов
попробуй: git mergetool
он открывает графический интерфейс, который проходит через каждый конфликт, и вы можете выбрать, как объединить. Иногда это требует немного ручного редактирования после этого, но обычно этого достаточно само по себе. Конечно, это гораздо лучше, чем делать все вручную.
согласно комментарию @JoshGlover:
Ниже приведен пример процедуры, чтобы использовать vimdiff для разрешения конфликтов слияния. На основе этой ссылке
Шаг 1: выполните следующие команды в вашем терминале
это установит vimdiff как слияние по умолчанию инструмент.
Шаг 2: выполните следующую команду в терминале
Шаг 3: вы увидите дисплей vimdiff в следующем формате
LOCAL-это файл из текущей ветви
BASE-общий предок, как файл выглядел до обоих изменений
REMOTE-файл, который вы объединяете в свою ветку
MERGED-merge result, это то, что сохраняется в репо
дополнительная информация о навигации vimdiff здесь и здесь
Шаг 4. Вы можете отредактировать объединенное представление следующим образом
если вы хотите получить изменения от Удаленный
если вы хотите получить изменения от базы
если вы хотите получить изменения от LOCAL
Шаг 5. Сохранить, выйти, совершить и очистить
:wqa сохранить и выйти из Vi
git clean удалить лишние файлы (например *.orig) создано инструментом diff.
вот вероятный вариант использования, сверху:
вы собираетесь тянуть некоторые изменения, но упс, вы не в курсе:
Итак, вы обновляетесь и повторяете попытку, но имеете конфликт:
Итак, вы решили взглянуть на изменения:
о меня, О мой, вверх по течению изменились некоторые вещи, но просто использовать мои изменения. нет. их изменения.
и затем мы попробуем финал время
Я нахожу, что инструменты слияния редко помогают мне понять конфликт или разрешение. Обычно я более успешно смотрю на маркеры конфликтов в текстовом редакторе и использую git log в качестве дополнения.
вот несколько советов:
Совет Один
лучшее, что я нашел, это использовать стиль конфликта слияния» diff3″:
git config merge.conflictstyle diff3
это создает маркеры конфликтов, такие как:
средний раздел Что похож на общего предка. Это полезно, потому что вы можете сравнить его с верхней и нижней версиями, чтобы получить лучшее представление о том, что было изменено на каждой ветке, что дает вам лучшее представление о цели каждого изменения.
если конфликт только несколько строк, это обычно делает конфликт очень очевидным. (Знание того, как исправить конфликт, совсем другое; вы должны знать, над чем работают другие люди. Если вас смущает, лучше просто назвать это человек в вашей комнате, чтобы они могли видеть, на что вы смотрите.)
если конфликт длиннее, то я буду вырезать и вставлять каждый из трех разделов в три отдельных файла, таких как «мой», «общий» и «их».
затем я могу запустить следующие команды, чтобы увидеть два разных куска, которые вызвали конфликт:
это не то же самое, что использовать инструмент слияния, так как инструмент слияния будет включать в себя все неконфликтные куски diff. Я считаю, что отвлекающий.
Совет Два
кто-то уже упоминал об этом, но понимание намерения за каждым отличием обычно очень полезно для понимания, откуда возник конфликт и как с ним справиться.
Это показывает все коммиты, которые коснулись этого файла между общим предком и двумя головами, которые вы объединяете. (Таким образом, он не включает коммиты, которые уже существуют в обеих ветвях до слияния.) Это поможет вам игнорировать diff hunks это явно не является фактором вашего нынешнего конфликта.
Совет Третий
Проверьте изменения с помощью автоматических инструментов.
если у вас есть автоматические тесты, запустите их. Если у вас есть Линта выполните это. Если это сборный проект, создайте его перед фиксацией и т. д. Во всех случаях, вам нужно сделать немного испытания, чтобы убедиться, что ваши изменения ничего не сломали. (Черт, даже слияние без конфликтов может нарушить рабочий код.)
Совет Четыре!—9—>
план вперед; общаться с коллегами.
планирование вперед и осознание того, над чем работают другие, может помочь предотвратить конфликты слияния и/или помочь разрешить их раньше-в то время как детали все еще свежи в памяти.
например, если вы знаете, что вы и другой человек работаете над разными рефакторингами, которые будут влиять на один и тот же набор файлов, вы должны заранее поговорить друг с другом и получить лучшее представление о том, какие типы файлов каждый из вас вносит изменения. Вы можете сэкономить значительное время и усилия, если будете проводить запланированные изменения последовательно, а не параллельно.
для основных рефакторингов, которые пересекают большую полосу кода, Вы должны настоятельно рассмотреть возможность работы последовательно: все перестают работать над этой областью кода, пока один человек выполняет полный рефакторинг.
если вы не можете работать последовательно (из-за давления времени, возможно), то сообщая об ожидаемых конфликтах слияния по крайней мере, поможет вам решить проблемы раньше, пока детали еще свежи в памяти. Например, если сотрудник совершает разрушительную серию коммитов в течение одной недели, вы можете выбрать слияние / ребазирование в этой ветви сотрудников один или два раза в день в течение этой недели. Таким образом, если вы найдете конфликты слияния/перебазирования, вы сможете решить их быстрее, чем если вы подождете несколько недель, чтобы объединить все вместе в один большой кусок.
Совет Пятый
если вы не уверены в слиянии, не форсируйте его.
слияние может показаться подавляющим, особенно когда есть много конфликтующих файлов и маркеры конфликтов охватывают сотни строк. Часто при оценке программных проектов мы не включаем достаточно времени для накладных расходов, таких как обработка узловатого слияния, поэтому кажется, что тратить несколько часов на разбор каждого конфликта-настоящее сопротивление.
в долгосрочной перспективе, планируя вперед и зная о том, что другие работают над лучшие инструменты для прогнозирования конфликтов слияния и подготовки к их правильному разрешению за меньшее время.
определите, какие файлы находятся в конфликте (Git должен сказать вам это).
откройте каждый файл и проверьте различия; Git разграничивает их. Надеюсь, будет очевидно, какую версию каждого блока сохранить. Возможно, вам придется обсудить это с другими разработчиками, которые совершили код.
проверьте ответы в вопросе переполнения стека прерывание слияния в Git, особенно ответ Чарльза Бейли который показывает, как просматривать различные версии файла с проблемами, например,
конфликты слияния происходят, когда изменения вносятся в файл одновременно. Вот как это решить.
git командной строки
вот простые шаги, Что делать, когда вы попадаете в конфликтное состояние:
разрешите конфликты отдельно для каждого файла одним из следующих подходов:
используйте GUI для решения конфликты: git mergetool (самый простой способ).
однако вы должны быть осторожны, так как удаленные изменения, что конфликты были сделаны по какой-то причине.
DiffMerge
Я успешно использовал DiffMerge который может визуально сравнивать и объединять файлы в Windows, macOS и Linux/Unix.
он графически может отображать изменения между 3 файлами и позволяет автоматическое слияние (когда это безопасно) и полный контроль над редактированием результирующего файла.
изображение: DiffMerge (скриншот в Linux)
просто загрузите его и запустите в репо as:
macOS
на macOS вы можете установить через:
и, вероятно (если не указано), вам нужна следующая дополнительная простая обертка, помещенная на вашем пути (например, /usr/bin ):
затем вы можете использовать следующие сочетания клавиш:
в качестве альтернативы вы можете использовать opendiff (часть инструментов Xcode), которая позволяет объединить два файла или каталога вместе, чтобы создать третий файл или каталог.
посмотреть Как Представлены Конфликты или, в Git, git merge документация, чтобы понять, что такое маркеры конфликтов слияния.
и как разрешить конфликты раздел объясняет, как разрешить конфликты:
, увидев конфликт, вы можете сделать две вещи:
разрешить конфликты. Git будет отмечать конфликты в рабочем дереве. Отредактируйте файлы в форму и git add их в индекс. Использовать git commit чтобы скрепить сделку.
вы можете работать через конфликт с рядом инструментов:
используйте mergetool. git mergetool для запуска графического mergetool, который будет поработайте над слиянием.
посмотрите на различия. git diff покажет трехсторонний diff, выделяя изменения от обоих HEAD и MERGE_HEAD версий.
сначала покажет различия для HEAD версия, а потом MERGE_HEAD версия.
смотреть на оригиналы. git show :1:filename показывает общего предка, git show :2:filename показывает HEAD версия, и git show :3:filename показывает MERGE_HEAD версия.
вы также можете прочитать о маркерах конфликтов слияния и о том, как их разрешить в Pro Git раздел книги Основные Конфликты Слияния.
на Emacs пользователи, которые хотят разрешить конфликты слияния полу-вручную:
показывает все файлы, требующие разрешения конфликтов.
открыть каждый из этих файлов по одному, или все сразу:
при посещении буфера, требующего редактирования в Emacs, введите
Это откроет три буфера (мой, их и выходной буфер). Перейдите, нажав » n «(следующая область), » p » (область предвидения). Нажмите ‘a’ и «b», чтобы скопировать мой или их регион в выходной буфер, соответственно. И / или редактировать выходной буфер напрямую.
когда закончите: нажмите «q». Emacs спрашивает вас, Хотите ли вы сохранить этот буфер: да. После завершения буфера отметьте его как разрешенный, запустив из териминала:
когда закончите со всеми буферами типа
для завершения слияния.
пожалуйста, выполните следующие действия, чтобы исправить конфликты слияния в Git:
проверьте состояние Git: git статус
получить набор патчей: git fetch (проверьте правильный патч из вашего git commit)
проверка локальной ветви (temp1 в моем примере здесь): git checkout-b temp1
запустите mergetool и проверьте конфликты и исправьте их. и проверьте изменения в удаленной ветви с вашей текущей веткой: git mergetool
проверьте состояние еще раз: git статус
удаление нежелательных файлов, локально созданных mergetool, обычно mergetool создает дополнительный файл с *.расширение ориг. Удалите этот файл, поскольку это просто дубликат и исправьте изменения локально и добавьте правильную версию своих файлов. git добавить #your_changed_correct_files
проверьте состояние еще раз: git статус
нажимаем в ветку master: git push (в ваш репозиторий Git)
просто, если вы хорошо знаете, что изменения в одном из репозиториев не важны, и хотите разрешить все изменения в пользу другого, используйте:
разрешить изменения в пользу хранилище или
разрешить изменения в пользу другое или главное хранилище.
и после завершения файла вам нужно будет сохранить и закрыть, чтобы открыть следующий.
Я либо хочу свою или их версию в полном объеме, либо хочу просмотреть отдельные изменения и решить для каждого из них.
полностью примите мою или их версию:
примите мою версию (локальную, нашу):
примите их версию (удаленную, их):
если вы хотите сделать для всех файлов конфликтов run:
просмотрите все изменения и примите их индивидуально
по умолчанию mergetool работает в командная строка. Как использовать командную строку mergetool должен быть отдельный вопрос.
вы также можете установить визуальный инструмент для этого, например, meld и работать
вы можете исправить конфликты слияния несколькими способами, как другие подробно.
Я думаю, что реальный ключ знает, как изменения протекают с локальными и удаленными репозиториями. Ключ к этому-понимание ветвей отслеживания. Я обнаружил, что я думаю о ветви отслеживания как о «недостающей части посередине» между моим локальным, фактическим каталогом файлов и удаленным, определенным как origin.
у меня лично вошло в привычку 2 вещи, чтобы помочь избежать этот.
a) все новые/измененные файлы добавляются, и это может включать некоторые нежелательные изменения.
b) вы не можете сначала просмотреть список файлов.
поэтому вместо этого я делаю:
[обновление-по прошествии времени я переключился больше на:
кроме того (и более уместно в вашей ситуации), я стараюсь избегать:
потому что pull подразумевает слияние, и если у вас есть изменения локально, которые вы не хотите объединять, вы можете легко получить объединенный код и / или объединить конфликты для кода, который не должен был быть слитый.