1. Определите, какие файлы конфликтуют (Git должен сообщить вам об этом).

2. Откройте каждый файл и изучите различия; Git их разграничивает. Надеюсь, будет очевидно, какую версию каждого блока оставить. Возможно, вам придется обсудить это с другими разработчиками, которые передали код.

3. После того, как вы разрешили конфликт в файле git add the_file.

4. После того, как вы разрешили конфликты все, выполните git rebase --continue или любую другую команду Git сказал сделать, когда вы закончите.

Если вы делаете частые небольшие коммиты, начните с просмотра комментариев к коммитам с git log --merge. Тогда git diff покажет вам конфликты.

Для конфликтов, включающих более нескольких строк, легче увидеть, что происходит, во внешнем инструменте с графическим интерфейсом пользователя. Мне нравится opendiff - Git также поддерживает vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, выход из коробки, и вы можете установить другие: git config merge.tool "your.tool" установит выбранный вами инструмент, а затем git mergetool после неудачного слияния покажет вам различия в контекст.

Каждый раз, когда вы редактируете файл для разрешения конфликта, git add filename будет обновлять индекс, и ваш diff больше не будет его отображать. Когда все конфликты обработаны и их файлы будут обработаны git add, git commit завершит ваше слияние.

Попробуйте: git mergetool

Он открывает графический интерфейс, который шаг за шагом проходит через каждый конфликт, и вы можете выбрать способ слияния. Иногда после этого требуется небольшое ручное редактирование, но обычно этого достаточно. Конечно, это намного лучше, чем делать все вручную.

Согласно комментарию @JoshGlover:

Команда

doesn't necessarily open a GUI unless you install one. Running git mergetool for me resulted in vimdiff being used. You can install one of the following tools to use it instead: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Ниже приведен пример процедуры использования vimdiff для разрешения конфликтов слияния. На основе эта ссылка

Шаг 1: Выполните следующие команды в своем терминале

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

Это установит vimdiff в качестве инструмента слияния по умолчанию.

Шаг 2: выполните следующую команду в терминале

git mergetool

Шаг 3: вы увидите дисплей vimdiff в следующем формате

  ╔═══════╦══════╦════════╗
  ║       ║      ║        ║
  ║ LOCAL ║ BASE ║ REMOTE ║
  ║       ║      ║        ║
  ╠═══════╩══════╩════════╣
  ║                       ║
  ║        MERGED         ║
  ║                       ║
  ╚═══════════════════════╝

Эти 4 представления являются

LOCAL – this is file from the current branch

BASE – common ancestor, how file looked before both changes

REMOTE – file you are merging into your branch

MERGED – merge result, this is what gets saved in the repo

Вы можете перемещаться между этими представлениями с помощью ctrl + w. Вы можете напрямую перейти к MERGED представлению, используя ctrl + w, за которым следует j.

Подробнее о навигации vimdiff здесь и здесь

Шаг 4. Вы можете отредактировать MERGED вид следующим образом

Если вы хотите получать изменения от REMOTE

:diffg RE  

Если вы хотите получить изменения от BASE

:diffg BA  

Если вы хотите получить изменения от LOCAL

:diffg LO 

Шаг 5. Сохранить, выйти, зафиксировать и очистить

:wqa сохранить и выйти из vi

git commit -m "message"

git clean Удалите лишние файлы (например, * .orig), созданные с помощью инструмента diff.

Ознакомьтесь с ответами на вопрос о переполнении стека Прерывание слияния в Git, особенно Ответ Чарльза Бейли, который показывает, как просматривать различные версии файла с проблемами, например,

# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp

Вот вероятный вариант использования сверху:

Вы собираетесь внести некоторые изменения, но, к сожалению, вы не в курсе:

git fetch origin
git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

Итак, вы обновляетесь и пытаетесь снова, но у вас конфликт:

git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

Итак, вы решили взглянуть на изменения:

git mergetool

Ой, боже мой, апстрим кое-что изменил, но просто чтобы использовать мои изменения ... нет ... их изменения ...

git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

А потом мы попробуем в последний раз

git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Та-да!

Я считаю, что инструменты слияния редко помогают мне разобраться в конфликте или разрешении. Обычно я более успешно смотрю на маркеры конфликтов в текстовом редакторе и использую git log в качестве дополнения.

Вот несколько советов:

Совет первый

Лучшее, что я нашел, - это использовать стиль конфликта слияния "diff3":

git config merge.conflictstyle diff3

Это создает такие маркеры конфликта:

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

Средняя часть - это то, как выглядел общий предок. Это полезно, потому что вы можете сравнить его с верхней и нижней версиями, чтобы лучше понять, что было изменено в каждой ветке, что дает вам лучшее представление о цели каждого изменения.

Если конфликт состоит всего из нескольких строк, это обычно делает конфликт очень очевидным. (Знать, как разрешить конфликт, совсем другое дело; вам нужно знать, над чем работают другие люди. Если вы запутались, вероятно, лучше всего просто позвать этого человека в свою комнату, чтобы они могли видеть, что вы ищете. в.)

Если конфликт будет более продолжительным, я вырежу и вставлю каждый из трех разделов в три отдельных файла, таких как «мой», «общий» и «их».

Затем я могу запустить следующие команды, чтобы увидеть два блока различий, вызвавших конфликт:

diff common mine
diff common theirs

Это не то же самое, что использовать инструмент слияния, поскольку инструмент слияния также будет включать все неконфликтующие блоки различий. Я считаю, что это отвлекает.

Совет второй

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

git log --merge -p <name of file>

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

Совет третий

Проверяйте свои изменения с помощью автоматических инструментов.

Если у вас есть автоматизированные тесты, запустите их. Если у вас есть ворсинок, запустите его. Если это собираемый проект, соберите его перед фиксацией и т. д. Во всех случаях вам нужно провести небольшое тестирование, чтобы убедиться, что ваши изменения ничего не сломали. (Черт возьми, даже слияние без конфликтов может нарушить рабочий код.)

Совет четвертый

Планируйте заранее; общаться с коллегами.

Предварительное планирование и осознание того, над чем работают другие, могут помочь предотвратить конфликты слияния и / или помочь разрешить их раньше - пока детали еще свежи в памяти.

Например, если вы знаете, что вы и другой человек оба работаете над разным рефакторингом, который повлияет на один и тот же набор файлов, вам следует поговорить друг с другом заранее и лучше понять, к каким типам изменений относится каждый из вас. изготовление. Вы можете значительно сэкономить время и силы, если будете проводить запланированные изменения последовательно, а не параллельно.

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

Если вы не можете работать последовательно (возможно, из-за нехватки времени), то сообщение об ожидаемых конфликтах слияния, по крайней мере, поможет вам решить проблемы раньше, пока детали еще свежи в памяти. Например, если ваш коллега выполняет серию разрушительных коммитов в течение недельного периода, вы можете выбрать объединение / перебазирование в этой ветке коллег один или два раза в день в течение этой недели. Таким образом, если вы обнаружите конфликты слияния / перебазирования, вы сможете решить их быстрее, чем если вы подождете несколько недель, чтобы объединить все вместе в один большой кусок.

Совет пятый

Если вы не уверены в слиянии, не форсируйте его.

Слияние может показаться ошеломляющим, особенно когда существует много конфликтующих файлов, а маркеры конфликтов покрывают сотни строк. Часто при оценке программных проектов мы не включаем достаточно времени для накладных расходов, таких как обработка грубого слияния, поэтому тратить несколько часов на анализ каждого конфликта кажется настоящим бременем.

В конечном итоге, планирование наперед и осведомленность о том, над чем работают другие, являются лучшими инструментами для предотвращения конфликтов слияния и подготовки к их правильному разрешению за меньшее время.

Для пользователей Emacs, которые хотят разрешать конфликты слияния полуручно:

git diff --name-status --diff-filter=U

показывает все файлы, требующие разрешения конфликтов.

Откройте каждый из этих файлов один за другим или все сразу:

emacs $(git diff --name-only --diff-filter=U)

При посещении буфера, требующего редактирования в Emacs, введите

ALT+x vc-resolve-conflicts

Это откроет три буфера (мой, их и выходной буфер). Для навигации нажмите «n» (следующий регион), «p» (регион предварительного видения). Нажмите «a» и «b», чтобы скопировать мою или их регион в выходной буфер соответственно. И / или редактировать выходной буфер напрямую.

Когда закончите: нажмите «q». Emacs спросит вас, хотите ли вы сохранить этот буфер: да. После завершения буфера пометьте его как разрешенное, запустив от терминала:

git add FILENAME

Когда закончите со всеми типами буферов

git commit

чтобы завершить слияние.

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

Я думаю, что главное знать, как происходят изменения в локальных и удаленных репозиториях. Ключ к этому - понимание ветвей отслеживания. Я обнаружил, что считаю ветвь отслеживания «недостающим звеном посередине» между моим локальным, фактическим каталогом файлов и удаленным, определенным как источник.

Я лично привык к двум вещам, которые помогут этого избежать.

Вместо:

git add .
git commit -m"some msg"

У которого есть два недостатка -

a) Добавляются все новые / измененные файлы, которые могут включать некоторые нежелательные изменения. б) Вы не можете предварительно просмотреть список файлов.

Вместо этого я делаю:

git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.

Таким образом, вы более осознанно выбираете, какие файлы нужно добавить, а также можете просмотреть список и немного подумать, используя редактор для сообщения. Я считаю, что это также улучшает мои сообщения о фиксации, когда я использую полноэкранный редактор вместо опции -m.

[Обновление - по прошествии времени я переключился на:

git status # Make sure I know whats going on
git add .
git commit # Then use the editor

]

Также (и это более актуально для вашей ситуации) я стараюсь избегать:

git pull

или же

git pull origin master.

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

Вместо этого я пытаюсь сделать

git checkout master
git fetch   
git rebase --hard origin/master # or whatever branch I want.

Вы также можете найти это полезным:

git branch, fork, fetch, merge, rebase и clone, в чем различия?

См. Как представлены конфликты или, в Git, документацию git merge, чтобы понять, что такое маркеры конфликта слияния.

Также в разделе Как разрешать конфликты объясняется, как разрешить конфликты:

After seeing a conflict, you can do two things:

• Decide not to merge. The only clean-ups you need are to reset the index file to the HEAD commit to reverse 2. and to clean up working tree changes made by 2. and 3.; git merge --abort can be used for this.

• Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and git add them to the index. Use git commit to seal the deal.

You can work through the conflict with a number of tools:

• Use a mergetool. git mergetool to launch a graphical mergetool which will work you through the merge.

• Look at the diffs. git diff will show a three-way diff, highlighting changes from both the HEAD and MERGE_HEAD versions.

• Look at the diffs from each branch. git log --merge -p <path> will show diffs first for the HEAD version and then the MERGE_HEAD version.

• Look at the originals. git show :1:filename shows the common ancestor, git show :2:filename shows the HEAD version, and git show :3:filename shows the MERGE_HEAD version.

Вы также можете прочитать о маркерах конфликтов слияния и о том, как их разрешить, в разделе книги Pro GitОсновные конфликты слияния.

Ответ CoolAJ86 резюмирует почти все. Если у вас есть изменения в обеих ветвях одного и того же фрагмента кода, вам придется выполнить слияние вручную. Откройте конфликтующий файл в любом текстовом редакторе, и вы должны увидеть следующую структуру.

(Code not in Conflict)
>>>>>>>>>>>
(first alternative for conflict starts here)
Multiple code lines here
===========
(second alternative for conflict starts here)
Multiple code lines here too    
<<<<<<<<<<<
(Code not in conflict here)

Выберите один из вариантов или их комбинацию таким образом, каким вы хотите видеть новый код, удаляя при этом знаки равенства и угловые скобки.

git commit -a -m "commit message"
git push origin master

Если вы не используете инструмент для слияния, сначала скопируйте свой код за пределы:

- `checkout master`
- `git pull` / get new commit
- `git checkout` to your branch
- `git rebase master`

Это разрешает конфликт, и вы можете скопировать свой код.

Если вы хотите выполнить слияние из ветки test в master, вы можете выполнить следующие действия:

Шаг 1: зайти в ветку

git checkout test

Шаг 2:

git pull --rebase origin master

Шаг 3: Если есть какие-то конфликты, перейдите к этим файлам, чтобы изменить их.

Шаг 4: добавить эти изменения

git add #your_changes_files

Шаг 5:

git rebase --continue

ШАГ 6: Если конфликт все еще существует, вернитесь к шагу 3 еще раз. Если конфликта нет, сделайте следующее:

git push origin +test

Шаг 7.: И тогда нет конфликта между тестом и мастером. Вы можете использовать слияние напрямую.

git log --merge -p [[--] path]

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

Чтобы обойти эту проблему, я открываю две командные строки и за один запуск

git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

а в другом

git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

Замена $MERGED_IN_BRANCH веткой, которую я объединил, и [path] конфликтующим файлом. Эта команда будет регистрировать все коммиты в форме патча между (..) двумя коммитами. Если вы оставите одну сторону пустой, как в приведенных выше командах, git автоматически будет использовать HEAD (ветвь, в которую вы в данном случае сливаетесь).

Это позволит вам увидеть, какие коммиты попали в файл в двух ветвях после того, как они разошлись. Обычно это значительно упрощает разрешение конфликтов.

Я всегда следую приведенным ниже инструкциям, чтобы избежать конфликтов.

• git checkout master (зайдите в главную ветку)
• git pull (обновите свой мастер, чтобы получить последний код)
• git checkout -b mybranch (оформить новую ветку a и начать работу над этой веткой, чтобы ваш мастер всегда оставался наверху ствола.)
• git add. И git commit И git push (в вашей локальной ветке после ваших изменений)
• git checkout master (вернитесь к своему мастеру.)

Теперь вы можете делать то же самое и поддерживать столько локальных веток, сколько хотите, и работать одновременно, просто выполняя проверку git для вашей ветки, когда это когда-либо необходимо.

Чтобы исправить конфликты слияния в Git, выполните следующие действия:

1. Проверьте статус Git: git статус

2. Получите патчсет: git fetch (проверьте правильный патч из вашего коммита Git)

3. Оформить заказ в локальном филиале (temp1 в моем примере здесь): git checkout -b temp1

4. Получите последнее содержимое от мастера: git pull --rebase origin master

5. Запустите mergetool и проверьте конфликты и исправьте их ... и проверьте изменения в удаленной ветке с вашей текущей веткой: git mergetool

6. Еще раз проверьте статус: git статус

7. Удалите ненужные файлы, локально созданные с помощью mergetool, обычно mergetool создает дополнительный файл с расширением * .orig. Пожалуйста, удалите этот файл, так как это всего лишь дубликат, исправьте изменения локально и добавьте правильную версию ваших файлов. git add #your_changed_correct_files

8. Еще раз проверьте статус: git статус

9. Зафиксируйте изменения с тем же идентификатором фиксации (это позволяет избежать нового отдельного набора патчей): git commit --amend

10. Отправьте в главную ветку: git push (в ваш репозиторий Git)

Конфликты слияния возникают, когда в файл одновременно вносятся изменения. Вот как это решить.

git CLI

Вот простые шаги, что делать, когда вы попадаете в конфликтное состояние:

1. Обратите внимание на список конфликтующих файлов: git status (в разделе Unmerged paths).

2. Разрешите конфликты отдельно для каждого файла одним из следующих способов:

   • Используйте графический интерфейс для разрешения конфликтов: git mergetool (самый простой способ).

   • Чтобы принять удаленную / другую версию, используйте: git checkout --theirs path/file. Это отклонит любые локальные изменения, которые вы сделали для этого файла.

   • Чтобы принять локальную / нашу версию, используйте: git checkout --ours path/file

     ^{However you've to be careful, as remote changes that conflicts were done for some reason.}

     Связанный: Каково точное значение «наших» и «их» в git?

   • Отредактируйте конфликтующие файлы вручную и найдите блок кода между <<<<< / >>>>>, затем выберите версию выше или ниже =====. См .: Как представлены конфликты.

   • Конфликты путей и имен файлов могут быть разрешены с помощью git add / git rm.

3. Наконец, просмотрите файлы, готовые к фиксации, используя: git status.

   Если у вас все еще есть какие-либо файлы в Unmerged paths, и вы разрешили конфликт вручную, сообщите Git, что вы разрешили его с помощью: git add path/file.

4. Если все конфликты были успешно разрешены, зафиксируйте изменения с помощью: git commit -a и отправьте на удаленное управление как обычно.

См. Также: Разрешение конфликта слияния из командной строки на GitHub

Для практического руководства проверьте: Сценарий 5 - Исправление конфликтов слияния с помощью Katacoda.

DiffMerge

Я успешно использовал DiffMerge, который может визуально сравнивать и объединять файлы в Windows, macOS и Linux / Unix.

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

^{Image source: DiffMerge (Linux screenshot)}

Просто скачайте его и запустите в репо как:

git mergetool -t diffmerge .

macOS

В macOS вы можете установить через:

brew install caskroom/cask/brew-cask
brew cask install diffmerge

И, вероятно (если не указан), вам понадобится следующая дополнительная простая оболочка, помещенная в ваш PATH (например, /usr/bin):

#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "$@"

Затем вы можете использовать следующие сочетания клавиш:

• ⌘-Alt-Up / Down для перехода к предыдущим / следующим изменениям.
• ⌘-Alt-Left / Right для принятия изменений слева или справа

В качестве альтернативы вы можете использовать opendiff (часть Xcode Tools), который позволяет объединить два файла или каталога вместе для создания третьего файла или каталога.

Бонус:

Говоря о pull / fetch / merge в приведенных выше ответах, я хотел бы поделиться интересным и продуктивным трюком,

git pull --rebase

Эта команда выше - самая полезная команда в моей жизни с git, которая сэкономила много времени.

Прежде чем отправлять недавно зафиксированное изменение на удаленный сервер, попробуйте git pull --rebase, а не git pull, и ручной merge, и он автоматически синхронизирует последние изменения удаленного сервера (с помощью fetch + merge) и поместит вашу последнюю локальную фиксацию вверху в журнал git. Не нужно беспокоиться о ручном извлечении / слиянии.

В случае конфликта просто используйте

git mergetool
git add conflict_file
git rebase --continue

Подробности на сайте: http://gitolite.com/git-pull--rebase

Просто, если вы хорошо знаете, что изменения в одном из репозиториев не важны, и хотите разрешить все изменения в пользу другого, используйте:

git checkout . --ours

принять изменения в пользу ваш репозиторий, или

git checkout . --theirs

разрешить изменения в пользу другой или основной репозиторий.

В противном случае вам придется использовать инструмент слияния с графическим интерфейсом пользователя, чтобы просматривать файлы один за другим, скажем, инструмент слияния - p4merge, или написать любое имя, которое вы уже установили.

git mergetool -t p4merge

а после завершения файла вам нужно будет сохранить и закрыть, поэтому откроется следующий.

Конфликты слияния могут возникать в разных ситуациях:

• При запуске git fetch, а затем git merge
• При запуске git fetch, а затем git rebase
• При запуске git pull (что фактически соответствует одному из вышеупомянутых условий)
• При запуске git stash pop
• Когда вы применяете патчи git (коммиты, которые экспортируются в файлы для передачи, например, по электронной почте)

Вам необходимо установить инструмент слияния, совместимый с Git, для разрешения конфликтов. Я лично использую KDiff3, и мне он показался приятным и удобным. Вы можете скачать его версию для Windows здесь:

https://sourceforge.net/projects/kdiff3/files/

Кстати, если вы устанавливаете Git Extensions, в его мастере установки есть опция для установки Kdiff3.

Затем настройте конфигурацию git, чтобы использовать Kdiff в качестве инструмента слияния:

$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false

$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false

(Не забудьте заменить путь фактическим путем к исполняемому файлу Kdiff.)

Затем каждый раз, когда вы сталкиваетесь с конфликтом слияния, вам просто нужно запускать эту команду:

$ git mergetool

Затем он открывает Kdiff3 и сначала пытается автоматически разрешить конфликты слияния. Большинство конфликтов будут разрешены спонтанно, а остальные нужно исправить вручную.

Вот как выглядит Kdiff3:

Затем, как только вы закончите, сохраните файл, и он перейдет к следующему файлу с конфликтом, и вы сделаете то же самое снова, пока все конфликты не будут разрешены.

Чтобы проверить, все ли успешно слито, просто запустите команду mergetool еще раз, вы должны получить следующий результат:

$ git mergetool
No files need merging

Я либо хочу свою или их версию полностью, либо хочу просмотреть отдельные изменения и принять решение по каждому из них.

Полностью принимаю мою или их версию:

Примите мою версию (местную, нашу):

git checkout --ours -- <filename>
git add <filename>              # Marks conflict as resolved
git commit -m "merged bla bla"  # An "empty" commit

Примите их версию (удаленную, их):

git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"

Если вы хотите запустить для всех конфликтных файлов:

git merge --strategy-option ours

или же

git merge --strategy-option theirs

Просмотрите все изменения и примите их индивидуально

1. git mergetool
2. Просмотрите изменения и примите любую версию для каждого из них.
3. git add <filename>
4. git commit -m "merged bla bla"

По умолчанию mergetool работает в командная строка. Как использовать mergetool из командной строки - это отдельный вопрос.

Вы также можете установить для этого визуальный инструмент, например meld и запустите

git mergetool -t meld

Он откроет локальную версию (нашу), «базовую» или «объединенную» версию (текущий результат слияния) и удаленную версию (их). По завершении сохраните объединенную версию, снова запустите git mergetool -t meld, пока не получите сообщение «Файлы не нужно объединять», затем переходите к шагам 3 и 4.

Использование patience

В случае большого конфликта слияния использование patience дало мне хорошие результаты. Он будет пытаться сопоставить блоки, а не отдельные строки.

Если вы, например, измените отступ своей программы, стратегия слияния Git по умолчанию иногда совпадает с одиночными фигурными скобками {, которые принадлежат разным функциям. Этого можно избежать с помощью patience:

git merge -s recursive -X patience other-branch

Из документации:

With this option, merge-recursive spends a little extra time to avoid 
mismerges that sometimes occur due to unimportant matching lines 
(e.g., braces from distinct functions). Use this when the branches to 
be merged have diverged wildly.

Сравнение с общим предком

Если у вас есть конфликт слияния и вы хотите увидеть, что другие имели в виду, изменяя свою ветку, иногда проще сравнить их ветку напрямую с общим предком (вместо нашей). Для этого вы можете использовать merge-base:

git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

Обычно вы хотите увидеть изменения только для определенного файла:

git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>

Более безопасный способ разрешения конфликтов - использовать мерзавец (общие решения, предлагаемые здесь, весьма подвержены ошибкам, imho).

См. эта почта для быстрого ознакомления с тем, как его использовать.

С 12 декабря 2016 г. вы можете объединять ветки и разрешать конфликты на github.com

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

Это сообщение в блоге объясняет подробно, но основы таковы, что после «слияния» двух ветвей через пользовательский интерфейс вы увидите опцию «разрешить конфликты», которая приведет вас к редактору, позволяющему справиться с этими конфликтами слияния.

Есть 3 шага:

1. Найдите файлы, вызывающие конфликты, по команде

   git status
   

2. Проверьте файлы, в которых вы обнаружите конфликты, помеченные как

   <<<<<<<<head
   blablabla
   

3. Измените его так, как вы хотите, затем зафиксируйте с помощью команд

   git add solved_conflicts_files
   git commit -m 'merge msg'
   

git fetch <br>
git checkout **your branch**<br>
git rebase master<br>

На этом шаге вы попытаетесь исправить конфликт, используя предпочитаемую вами IDE.

Вы можете следить за эта ссылка, чтобы проверить, как исправить конфликт в файле

git add<br>
git rebase --continue<br>
git commit --amend<br>
git push origin HEAD:refs/drafts/master  (push like a drafts)<br>

Теперь все в порядке, и вы найдете свой коммит в gerrit
.

Я надеюсь, что это поможет всем, кто имеет отношение к этому вопросу.

Для тех, кто использует Visual Studio (в моем случае 2015)

1. Закройте свой проект в VS. VS особенно в больших проектах, как правило, нервничает при слиянии с использованием пользовательского интерфейса.

2. Выполните слияние в командной строке.

   git checkout target_branch

   git merge source_branch

3. Затем откройте проект в VS и перейдите в Team Explorer -> Branch. Теперь появляется сообщение о том, что слияние ожидает, а конфликтующие файлы перечислены прямо под сообщением.

4. Щелкните конфликтующий файл, и у вас будет возможность объединить, сравнить, взять источник, взять цель. Инструмент слияния в VS очень прост в использовании.

Если вы используете intelliJ как IDE Попробуйте объединить родителя с вашей веткой с помощью

git checkout <localbranch>
git merge origin/<remotebranch>

Он покажет все подобные конфликты

A_MBPro:test anu$ git merge origin/ Auto-merging src/test/java/com/.../TestClass.java CONFLICT (content): Merge conflict in src/test/java/com/.../TestClass.java

Теперь обратите внимание, что файл TestClass.java отображается красным цветом в intelliJ. Также будет отображаться статус git

Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   src/test/java/com/.../TestClass.java

Откройте файл в intelliJ, в нем будут разделы с

  <<<<<<< HEAD
    public void testMethod() {
    }
    =======
    public void testMethod() { ...
    }
    >>>>>>> origin/<remotebranch>

где HEAD - это изменения в вашей локальной ветке, а origin / - это изменения из удаленной ветки. Здесь сохраните то, что вам нужно, и удалите ненужное. После этого следует выполнить обычные действия. То есть

   git add TestClass.java
   git commit -m "commit message"
   git push

git checkout branch1

git fetch origin

git rebase -p origin/mainbranch

Если есть конфликты слияния, исправьте их. Затем продолжите процесс перебазирования, запустив: git rebase –-continue

после исправления вы можете зафиксировать и нажать свою локальную ветку на удаленную ветку

git push origin branch1

Я следую приведенному ниже процессу.

Процесс устранения конфликта слияния:

1. Сначала извлеките последнюю версию из целевой ветки, с которой вы хотите объединить git pull origin develop.

2. Поскольку вы получаете последнюю информацию из пункта назначения, теперь разрешите конфликт вручную в IDE, удалив эти лишние символы.

3. Сделайте git add, чтобы добавить эти отредактированные файлы в очередь git, чтобы они могли быть commit и push в той же ветке, над которой вы работаете.

4. Как только git add будет готов, сделайте git commit, чтобы зафиксировать изменения.

5. Теперь внесите изменения в вашу рабочую ветку с помощью git push origin HEAD.

Вот и все, и вы увидите, что это разрешено в вашем запросе на перенос, если вы используете Bitbucket или GitHub.

Эти ответы предназначены для добавления альтернативы тем пользователям VIM, как я, которые предпочитают делать все в редакторе.

TL; DR

Tpope придумал замечательный плагин для VIM под названием беглец. После установки вы можете запустить :Gstatus, чтобы проверить файлы, у которых есть конфликты, и :Gdiff, чтобы открыть Git тремя способами слияния.

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

• :diffget //2, получите изменения из исходной (ГОЛОВА) ветки:
• :diffget //3, получите изменения из ветки слияния:

Когда вы закончите объединение файла, введите :Gwrite в объединенный буфер. Vimcasts выпустили отличный видео, подробно объясняющий эти шаги.

Попробуйте редактировать Visual Studio Code, если вы еще этого не сделали. Что он делает, так это после попытки слияния (и попадания в конфликт слияния) .VS-код автоматически обнаруживает конфликты слияния.

Он может вам очень помочь, показывая, какие изменения были внесены в исходный, и следует ли вам принимать incoming или

current change (имеется в виду исходный до слияния) '?.

Это помогло мне, и это может сработать и для вас!

PS: Это будет работать, только если вы настроили git с помощью своего кода и кода Visual Studio.

Gitlense для VS Code

Вы можете попробовать Гитленсе для VS Code, их ключевые особенности:

3. Легко разрешайте конфликты.

Мне уже нравится эта функция:

2. Авторство текущей линии.

3. Виноват в желобе

4. Виноват в строке состояния

И есть много функций, которые вы можете проверить на них здесь.

Я использую Microsoft Visual Code для разрешения конфликтов. Его очень просто использовать. Я оставляю свой проект открытым в рабочей области. Он обнаруживает и выделяет конфликты, кроме того, предоставляет параметры графического интерфейса для выбора любых изменений, которые я хочу сохранить от HEAD или входящих.

Если вы просто хотите восстановить удаленный мастер, тогда

git reset --hard origin/master

ПРЕДУПРЕЖДЕНИЕ: Все локальные изменения будут потеряны, см. https://stackoverflow.com/a/8476004/11769765.

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

До сих пор никто не упоминал WinMerge в этом следе, поэтому я упоминаю здесь.

Конфликт слияния Git сообщает вам, что ваш пул реквест отменит / потеряет / перезапишет изменения сотрудника, как правило, из-за того, что ваша копия контента была недостаточно свежей.

Шаги по разрешению могут быть следующими:

• Возьмите еще один новый клон исходного кода в папку с новым именем,
• Используйте WinMerge для сравнения вашего контента и самого последнего контента, чтобы понять конфликт,
• Для файлов, измененных вами и вашим коллегой, которые вызывают конфликт Git Merge, посмотрите на строки, которые ваш коллега добавил / изменил / удалил, по сравнению со строками кода, которые вы добавили / изменено / удалено.
• Используйте стрелки перемещения раздела кода winmerge влево / вправо, чтобы убедиться, что работа ваших коллег находится в вашей копии файла, и вы не засоряете их работу.

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

Я так думаю.

Примечание: WinMerge создает файлы .bak ... и вы не хотите, чтобы они копировались в систему управления версиями AzOps / TFS и т. д., Поэтому, если вы уверены, что выполнили редактирование правильно, удалите файлы .bak.

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

Однако ответ на ваш вопрос прост и разочаровывает. Конфликты слияния почти всегда решаются вручную вручную. Если вы используете такой инструмент, как, например, GitLab, графический интерфейс может помочь вам найти различия в двух версиях кода, но в конце концов вы должны решить, какую строку следует сохранить, а какую удалить.

Простой пример: программист A и программист B отправляют один и тот же - по-разному измененный - файл в удаленный репозиторий. Программист A открывает запрос на слияние, и GitLab выделяет несколько строк кода, в которых возникают конфликты между двумя версиями. Теперь программисты А и Б должны решить, кто лучше написал код в этих конкретных строках. Им нужно идти на компромиссы.

Я понял, что такое конфликт слияния, но когда я увидел результат git diff, мне сначала это показалось бессмысленным:

git diff
++<<<<<<< HEAD 
 + display full last name boolean in star table 
++=======
+ users viewer.id/star.id, and conversation uses user.id
+ 
++>>>>>>> feat/rspec-tests-for-cancancan

Но мне помог здесь:

• Все между <<<<<<< и ======= - это то, что было в одном файле и

• Все между ======= и >>>>>>> - это то, что было в другом файле

• Таким образом, буквально все, что вам нужно сделать, это удалить эти строки из любой ветки (или просто сделать их одинаковыми), и merge немедленно добьется успеха. Проблема решена!

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

Добавить / зафиксировать / нажать, и все хорошо.