Как разрешить конфликты слияния в Git?

3861

Есть ли хороший способ объяснить, как разрешать конфликты слияния в Git?

задан Spoike 02 окт. '08 в 14:31
источник

33 ответов

  • 1
  • 2
2181

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

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

В соответствии с комментарием @JoshGlover:

Команда не обязательно открывает графический интерфейс, если вы его не установили. Выполнение git mergetool для меня привело к использованию vimdiff. Вместо этого вы можете установить один из следующих инструментов: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

ответ дан Peter Burns 02 окт. '08 в 20:50
источник
1549

Здесь вероятный прецедент, сверху:

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

git fetch origin
git pull origin master

From ssh://gitosis@example.com: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://gitosis@example.com: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://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Та-да!

ответ дан CoolAJ86 04 авг. '10 в 20:04
источник
653

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

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

Совет один

Самое лучшее, что я нашел, это использовать стиль конфликта слияния "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

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

Совет два

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

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

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

Совет три

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

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

Совет четыре

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

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

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

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

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

Совет пять

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

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

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

ответ дан Mark E. Haase 29 сент. '11 в 0:08
источник
308
  • Определите, какие файлы находятся в конфликте (Git должен сказать вам это).

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

  • Как только вы разрешили конфликт в файле git add the_file.

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

ответ дан davetron5000 02 окт. '08 в 15:41
источник
90

Проверьте ответы в вопросе Отмена слияния в 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
ответ дан Pat Notz 03 окт. '08 в 18:15
источник
80

Слияние конфликтов происходит, когда изменения вносятся в файл одновременно. Вот как это можно решить.

git CLI

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

  • Обратите внимание на список конфликтующих файлов: git status (в разделе Unmerged paths).
  • Решите конфликты отдельно для каждого файла одним из следующих подходов:

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

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

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

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

      Связано: Каково точное значение "ours" и "их" в git?

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

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

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

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

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

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

DiffMerge

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

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

DiffMerge

Источник изображения: DiffMerge (снимок экрана Linux)

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

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), которая позволяет объединить два файла или каталоги вместе, чтобы создать третий файл или каталог.

ответ дан kenorb 05 авг. '15 в 17:29
источник
70

Если вы делаете частые мелкие коммиты, начните с просмотра комментариев коммита с помощью git log --merge. Затем git diff покажет вам конфликты.

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

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

ответ дан Paul 02 окт. '08 в 19:11
источник
39

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

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

После просмотра конфликта вы можете сделать две вещи:

  • Решите не сливаться. Единственные очистители, которые вам нужны, - это reset индексный файл для фиксации HEAD для обратного преобразования 2. и для очистки рабочих деревенских изменений, сделанных в 2. и 3; git merge --abort можно использовать для этого.

  • Разрешить конфликты. Git будет отмечать конфликты в рабочем дереве. Отредактируйте файлы в форме и git add их в индекс. Используйте git commit, чтобы запечатать сделку.

Вы можете работать в конфликте с помощью нескольких инструментов:

  • Используйте mergetool. git mergetool, чтобы запустить графический mergetool, который будет работать через слияние.

  • Посмотрите на различия. git diff отображает трехсторонний diff, выделяя изменения как из версий HEAD, так и MERGE_HEAD.

  • Посмотрите на различия между каждой ветвью. git log --merge -p <path> будет показывать diff сначала для версии HEAD, а затем версии MERGE_HEAD.

  • Посмотрите на оригиналы. git show :1:filename показывает общего предка, git show :2:filename показывает версию HEAD, а git show :3:filename показывает версию MERGE_HEAD.

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

ответ дан user456814 14 июля '13 в 21:34
источник
34

Для 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

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

ответ дан eci 23 февр. '13 в 2:04
источник
25

Для устранения конфликтов слияния в git выполните следующие действия:

  • Проверьте статус git: git статус

  • Получить патчсет: git fetch (проверьте правильный патч из вашей фиксации git)

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

  • Потяните последнее содержимое от мастера: git pull --rebase origin master

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

  • Проверьте статус еще раз:   git статус

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

  • снова проверьте статус: git статус

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

  • Нажмите на главную ветку: git нажмите (в репозиторий git)

ответ дан Chhabilal 16 апр. '15 в 10:02
источник
22

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

git checkout . --ours

чтобы разрешить изменения в пользу вашего репозитория или

git checkout . --theirs

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

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

git mergetool -t p4merge

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

ответ дан Mohamed Selim 26 янв. '16 в 20:42
источник
22

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

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

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

Вместо:

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 ветвь, fork, fetch, merge, rebase и clone, каковы различия?

ответ дан Michael Durrant 19 апр. '13 в 4:08
источник
20

Бонус:

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

git pull --rebase

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

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

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

git mergetool
git add conflict_file
git rebase --continue

Найти информацию по адресу: http://gitolite.com/git-pull--rebase

ответ дан Sazzad Hissain Khan 25 дек. '15 в 18:24
источник
18

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

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

Примите мою версию (local, ours):

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

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

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

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

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

git mergetool -t meld

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

ответ дан Noidea 29 сент. '16 в 16:02
источник
18

Ответ 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
ответ дан iankit 25 янв. '14 в 19:17
источник
13

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

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

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

введите описание изображения здесь

ответ дан maxwell 09 янв. '17 в 22:45
источник
13
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 (ветвь, в которую вы сливаетесь в этом случае).

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

ответ дан Brian Di Palma 11 дек. '14 в 18:19
источник
10

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

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

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

ответ дан Chetan 12 февр. '15 в 7:25
источник
9

если вы хотите слить из ветки (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: и тогда между тестом и мастером нет конфликта. вы можете использовать слияние напрямую.

ответ дан Haimei 18 авг. '14 в 22:42
источник
9

Использование терпения

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

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

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>
ответ дан Conchylicultor 30 нояб. '16 в 22:51
источник
8

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

  • При запуске "git fetch", а затем "git merge"
  • При запуске "git fetch", а затем "git rebase"
  • При запуске "git pull" (что фактически соответствует одному из вышеупомянутых условий)
  • При запуске "git всплывающее окно"
  • При применении патчей git (фиксации, которые экспортируются в файлы, которые будут переданы, например, по электронной почте).

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

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

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

Затем настройте git configs, чтобы использовать Kdiff как его mergetool:

$ 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

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

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

$git mergetool 

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

Вот что выглядит Kdiff3: введите описание изображения здесь

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

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

$git mergetool
No files need merging
ответ дан akazemis 18 июня '16 в 8:29
источник
5

Есть три шага:

  • Найти, какие файлы вызывают конфликты командой
    git status
  1. Проверьте файлы, в которых вы найдете конфликты, отмеченные как

    <<<<<<<<head blablabla

  2. Измените способ, которым вы хотите, затем с командами

    git add solved_conflicts_files
    git commit -m 'merge msg'
ответ дан Qijun Liu 23 июня '17 в 17:38
источник
3

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


TL; DR

введите описание изображения здесь


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

Как только в 3-way merge, беглец позволит вам получить изменения любой из ветвей, которые вы объединяете, следующим образом:

  • :diffget //2, получите изменения от ветки оригинала (HEAD):
  • :diffget //3, получите изменения от слияния ветки:

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

ответ дан Vicente Adolfo Bolea Sánchez 16 окт. '17 в 9:01
источник
1

git fetch
git checkout ваша ветка
git мастер переадресации

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

Вы можете перейти по этой ссылке, чтобы проверить ho, чтобы исправить конфликт в файле
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/

git добавить
git rebase - продолжить git commit --amend
git push origin HEAD: refs/drafts/master (нажмите, как черновики)

Теперь все прекрасно, и вы найдете свою фиксацию в геррите

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

ответ дан Baini.Marouane 05 июля '17 в 16:25
источник
1

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

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

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

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

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

  • Как git add, выполните a git commit, чтобы зафиксировать изменения.

  • Теперь переместите изменения в рабочую ветвь на git push origin HEAD

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

ответ дан Aniruddha Das 14 окт. '17 в 0:49
источник
0

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

https://githowto.com/resolving_conflicts

https://confluence.atlassian.com/bitbucket/resolve-merge-conflicts-704414003.html

ответ дан Always_Beginner 02 дек. '17 в 20:53
0

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

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

ответ дан yairchu 29 дек. '17 в 19:46
источник
0

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

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

  • Сделайте слияние в командной строке.

    git checkout target_branch

    git merge source_branch

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

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

ответ дан Mike 10 июля '17 в 23:29
источник
0

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

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

Он отобразит все конфликты вроде этого

A_MBPro: test anu $ git слияние источника/автоматическое слияние src/test/java/com/.../TestClass.java CONFLICT (содержание): Объединить конфликт в SRC/тест/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
ответ дан AJC 11 июля '17 в 19:23
источник
0

git ветвь checkout1

git fetch происхождение

git rebase -p origin/mainbranch

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

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

git push origin branch1

ответ дан Vinayak Shedgeri 08 авг. '17 в 11:41
источник
  • 1
  • 2

Ознакомьтесь с другими вопросами по меткам