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

вы собираетесь тянуть некоторые изменения, но упс, вы не в курсе:

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.

та-да!

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

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

Совет Два

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

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

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

Совет Третий

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

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

Совет Четыре!--9-->

план вперед; общаться с коллегами.

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

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

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

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

Совет Пятый

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

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

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

1. определите, какие файлы находятся в конфликте (Git должен сказать вам это).

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

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

4. как только вы разрешите все конфликты, do git rebase --continue или то, что команда ГИТ сказал сделать, когда вы закончите.

проверьте ответы в вопросе переполнения стека прерывание слияния в 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 командной строки

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

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

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

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

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

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

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

     по теме: каково точное значение "наших" и" их " в ГИТ?

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

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

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

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

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

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

DiffMerge

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

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

^{изображение: DiffMerge (скриншот в Linux)}

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

git mergetool -t diffmerge .

macOS

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

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

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

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

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

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

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

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

для конфликтов, которые включают более нескольких строк, легче увидеть, что происходит во внешнем инструменте GUI. Мне нравится 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,git merge документация, чтобы понять, что такое маркеры конфликтов слияния.

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

, увидев конфликт, вы можете сделать две вещи:

• решили не сливаться. Единственные очистки, которые вам нужны, - это сброс индексного файла в 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> сначала покажет различия для HEAD версия, а потом MERGE_HEAD версия.

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

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

на 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:

1. проверьте состояние Git: git статус

2. получить набор патчей: git fetch (проверьте правильный патч из вашего git commit)

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

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

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

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

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

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

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

10. нажимаем в ветку master: git push (в ваш репозиторий Git)

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

git checkout . --ours

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

git checkout . --theirs

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

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

git mergetool -t p4merge

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

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

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

примите мою версию (локальную, нашу):

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"

если вы хотите сделать для всех файлов конфликтов run:

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.

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

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

у меня лично вошло в привычку 2 вещи, чтобы помочь избежать этот.

вместо:

git add .
git commit -m"some msg"

, который имеет два недостатка -

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

поэтому вместо этого я делаю:

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

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

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

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

бонус:

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

git pull --rebase

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

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

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

git mergetool
git add conflict_file
git rebase --continue

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

ответ 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

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 (ветвь, в которую вы сливаетесь в этом случае).

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

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

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

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

есть 3 шага:

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

   git status
   

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

   <<<<<<<<head
   blablabla
   

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

   git add solved_conflicts_files
   git commit -m 'merge msg'
   

используя patience

я удивлен, что никто не говорит о разрешении конфликта с помощью 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>

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

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

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

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

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

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

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

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

BTW если вы устанавливаете расширения Git, в мастере установки есть опция для установки 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

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

TL; DR

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

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

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

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

git fetch
ГИТ кассе ваш филиал
ГИТ перебазирования мастер

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

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

в Git добавить
ГИТ перебазирования --продолжить
в Git коммит --изменения
git push origin HEAD:refs / черновики / master (нажмите, как черновики)

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

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

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

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

current change(что означает оригинал перед слиянием)'?.

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

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

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

1. закройте проект в VS. Особенно в больших проектах VS имеет тенденцию волноваться при слиянии с использованием пользовательского интерфейса.

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

   git checkout target_branch

   git merge source_branch

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

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

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

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

он покажет все конфликты, как это

A_MBPro: тест ANU$ git merge origin / автоматическое слияние src / test / java / com/.../класс TestClass.конфликт java (содержание): конфликт слияния в 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

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

процесс исправления конфликта слияния:

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

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

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

4. As git add готово, сделайте git commit для фиксации изменений.

5. теперь нажмите изменения в вашей рабочей ветви на git push origin HEAD

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

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

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

git checkout branch1

git fetch origin

git rebase -p origin/mainbranch

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

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

git push origin branch1