this branch has conflicts that must be resolved что делать
Resolving a merge conflict on GitHub
You can resolve simple merge conflicts that involve competing line changes on GitHub, using the conflict editor.
You can only resolve merge conflicts on GitHub that are caused by competing line changes, such as when people make different changes to the same line of the same file on different branches in your Git repository. For all other types of merge conflicts, you must resolve the conflict locally on the command line. For more information, see «Resolving a merge conflict using the command line.»
Warning: When you resolve a merge conflict on GitHub, the entire base branch of your pull request is merged into the head branch. Make sure you really want to commit to this branch. If the head branch is the default branch of your repository, you’ll be given the option of creating a new branch to serve as the head branch for your pull request. If the head branch is protected you won’t be able to merge your conflict resolution into it, so you’ll be prompted to create a new head branch. For more information, see «About protected branches.»
Under your repository name, click
Pull requests.
In the «Pull Requests» list, click the pull request with a merge conflict that you’d like to resolve.
Tip: If the Resolve conflicts button is deactivated, your pull request’s merge conflict is too complex to resolve on GitHub. You must resolve the merge conflict using an alternative Git client, or by using Git on the command line. For more information see «[Resolving a merge conflict using the command line](/github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line.»
If you have more than one merge conflict in your file, scroll down to the next set of conflict markers and repeat steps four and five to resolve your merge conflict.
If you have more than one file with a conflict, select the next file you want to edit on the left side of the page under «conflicting files» and repeat steps four through seven until you’ve resolved all of your pull request’s merge conflicts. 
Once you’ve resolved all your merge conflicts, click Commit merge. This merges the entire base branch into your head branch. 
If prompted, review the branch that you are committing to.
If the head branch is the default branch of the repository, you can choose either to update this branch with the changes you made to resolve the conflict, or to create a new branch and use this as the head branch of the pull request. 
If you choose to create a new branch, enter a name for the branch.
If the head branch of your pull request is protected you must create a new branch. You won’t get the option to update the protected branch.
Click Create branch and update my pull request or I understand, continue updating BRANCH. The button text corresponds to the action you are performing.
To merge your pull request, click Merge pull request. For more information about other pull request merge options, see «Merging a pull request.»
The GitHub Blog
It’s going to happen one day. One of your students tries to merge one branch into another, and the dreaded error appears:
When changes in two branches overlap, Git shouts out for a clever human (like you or one of your students) to reconcile the differences. Even if you follow all the best practices of Git—communicate with your collaborators, pull in changes regularly, and make commits that are small, logical chunks—merge conflicts can still happen.
But merge conflicts don’t have to be scary for you or your students! In this post you’ll learn how to help students resolve them.
Why do merge conflicts happen?
There are many situations when a merge conflict can happen—when a student pulls in changes from a repository, after they open a pull request, or when they push changes to another repository (there are other, less common situations too, like unstashing, cherry picking, and rebasing, that won’t be covered here). Let’s look at a few examples:
Each of these situations leads to a merge conflict, but the process for resolving them is similar.
Yours, mine, and ours: resolving merge conflicts
When Git encounters a conflict, it pauses whatever it was doing (like pulling changes) and asks you to resolve the conflict. To help you sort out the situation, Git inserts conflict markers into your files, showing you what your changes are and what your collaborators’ changes are. Conflict markers look like this:
In this example, Students Frank and Helen have both modified README.md. Frank’s change has been merged to master while Helen’s changes are on a local topic branch. Helen discovered this when she tried to merge the changes from master into her topic branch.
Helen looks closely at the conflicting line. Both students have made roughly the same change to the file by adding a link, but Frank’s change includes a typo. Helen decides to keep her version (HEAD) and discard Frank’s (master). She does this by deleting Frank’s changes and the conflict markers, like this:
When she’s done resolving the conflict, she runs git add README.md to tell Git. Satisfied with her changes, she runs git commit to finish the merge.
Consider another example, however, where Helen and Frank have both changed the same line in different ways. Before either of their changes, the file they’re both working on contains this line:
In this example, Frank has expanded the sentence while Helen has added a filename. Helen pulls in the changes and sees these conflict markers:
It doesn’t make much sense to choose one side over the other, so Git offers another option: write a new line that wasn’t in either side’s commit history. Like this:
If there are more conflicts, then Git will insert conflict markers for each conflicting chunk it finds. Resolving many conflicts is like resolving one, except there are more conflict markers to tidy up. Walk through them one-by-one to resolve all the conflicts in all of the affected files. When you’re finished, add the files and commit.
Resolving conflicts in pull requests
Sometimes you’ll see a merge conflict in the context of a pull request.
A conflict in a pull request is like one on the command line. In a pull request, you can discuss with your collaborators how you plan to resolve merge conflicts and revise your branch.
The first option: the pull request author can update their branch. Since pull requests work with branches, you can often resolve a merge conflict by adding one or more commits to the incoming branch. For example, you can merge changes locally (e.g. git merge master ) and push the branch with the newly-added merge commit to GitHub.
If it’s a complicated conflict, you can discuss the best approach right from the pull request comments. Alternatively, you can amend your pull request (for example, by rebasing the incoming branch or amending a previous commit). This can be confusing at times, especially if there’s already been discussion in the comments.
Another option is to let the person accepting the pull request resolve the conflict while merging it. You can do this within the web interface using the GitHub editor or with the command line instructions GitHub provides—either way, it’s just like resolving a conflict with Git alone by choosing the resulting lines and removing conflict markers.
Bringing it back to the classroom
Resolving merge conflicts under a deadline might not be the best time for students to learn about them. Deliberately introducing merge conflicts in the classroom can help students when it comes time to handle them on their own. Check out Dr. Mine Çetinkaya-Rundel’s talk in which she shares how she teaches students Git skills, including resolving merge conflicts.
Want to learn even more about helping students understand and resolve merge conflicts? Check out the Campus Advisors learning module #3. This video course will help you learn more about group work, pull requests, and how to get your students comfortable with resolving conflicts.
Do you have an assignment you like to use to teach merge conflicts? Let us know in the GitHub Education Community.
Resolving a merge conflict using the command line
In this article
You can resolve merge conflicts using the command line and a text editor.
Merge conflicts occur when competing changes are made to the same line of a file, or when one person edits a file and another person deletes the same file. For more information, see «About merge conflicts.»
Tip: You can use the conflict editor on GitHub to resolve competing line change merge conflicts between branches that are part of a pull request. For more information, see «Resolving a merge conflict on GitHub.»
Competing line change merge conflicts
To resolve a merge conflict caused by competing line changes, you must choose which changes to incorporate from the different branches in a new commit.
For example, if you and another person both edited the file styleguide.md on the same lines in different branches of the same Git repository, you’ll get a merge conflict error when you try to merge these branches. You must resolve this merge conflict with a new commit before you can merge these branches.
Navigate into the local Git repository that has the merge conflict.
Generate a list of the files affected by the merge conflict. In this example, the file styleguide.md has a merge conflict.
Open your favorite text editor, such as Atom, and navigate to the file that has merge conflicts.
Add or stage your changes.
Commit your changes with a comment.
You can now merge the branches on the command line or push your changes to your remote repository on GitHub and merge your changes in a pull request.
Removed file merge conflicts
To resolve a merge conflict caused by competing changes to a file, where a person deletes a file in one branch and another person edits the same file, you must choose whether to delete or keep the removed file in a new commit.
For example, if you edited a file, such as README.md, and another person removed the same file in another branch in the same Git repository, you’ll get a merge conflict error when you try to merge these branches. You must resolve this merge conflict with a new commit before you can merge these branches.
Navigate into the local Git repository that has the merge conflict.
Generate a list of the files affected by the merge conflict. In this example, the file README.md has a merge conflict.
Open your favorite text editor, such as Atom, and navigate to the file that has merge conflicts.
Decide if you want keep the removed file. You may want to view the latest changes made to the removed file in your text editor.
To add the removed file back to your repository:
To remove this file from your repository:
Commit your changes with a comment.
You can now merge the branches on the command line or push your changes to your remote repository on GitHub and merge your changes in a pull request.
Как разрешать конфликты слияния в Git
есть ли хороший способ объяснить, как разрешить конфликты слияния в Git?
30 ответов
попробуй: git mergetool
он открывает графический интерфейс, который проходит через каждый конфликт, и вы можете выбрать, как объединить. Иногда это требует немного ручного редактирования после этого, но обычно этого достаточно само по себе. Конечно, это гораздо лучше, чем делать все вручную.
согласно комментарию @JoshGlover:
Ниже приведен пример процедуры, чтобы использовать vimdiff для разрешения конфликтов слияния. На основе этой ссылке
Шаг 1: выполните следующие команды в вашем терминале
это установит vimdiff как слияние по умолчанию инструмент.
Шаг 2: выполните следующую команду в терминале
Шаг 3: вы увидите дисплей vimdiff в следующем формате
LOCAL-это файл из текущей ветви
BASE-общий предок, как файл выглядел до обоих изменений
REMOTE-файл, который вы объединяете в свою ветку
MERGED-merge result, это то, что сохраняется в репо
дополнительная информация о навигации vimdiff здесь и здесь
Шаг 4. Вы можете отредактировать объединенное представление следующим образом
если вы хотите получить изменения от Удаленный
если вы хотите получить изменения от базы
если вы хотите получить изменения от LOCAL
Шаг 5. Сохранить, выйти, совершить и очистить
:wqa сохранить и выйти из Vi
git clean удалить лишние файлы (например *.orig) создано инструментом diff.
вот вероятный вариант использования, сверху:
вы собираетесь тянуть некоторые изменения, но упс, вы не в курсе:
Итак, вы обновляетесь и повторяете попытку, но имеете конфликт:
Итак, вы решили взглянуть на изменения:
о меня, О мой, вверх по течению изменились некоторые вещи, но просто использовать мои изменения. нет. их изменения.
и затем мы попробуем финал время
Я нахожу, что инструменты слияния редко помогают мне понять конфликт или разрешение. Обычно я более успешно смотрю на маркеры конфликтов в текстовом редакторе и использую git log в качестве дополнения.
вот несколько советов:
Совет Один
лучшее, что я нашел, это использовать стиль конфликта слияния» diff3″:
git config merge.conflictstyle diff3
это создает маркеры конфликтов, такие как:
средний раздел Что похож на общего предка. Это полезно, потому что вы можете сравнить его с верхней и нижней версиями, чтобы получить лучшее представление о том, что было изменено на каждой ветке, что дает вам лучшее представление о цели каждого изменения.
если конфликт только несколько строк, это обычно делает конфликт очень очевидным. (Знание того, как исправить конфликт, совсем другое; вы должны знать, над чем работают другие люди. Если вас смущает, лучше просто назвать это человек в вашей комнате, чтобы они могли видеть, на что вы смотрите.)
если конфликт длиннее, то я буду вырезать и вставлять каждый из трех разделов в три отдельных файла, таких как «мой», «общий» и «их».
затем я могу запустить следующие команды, чтобы увидеть два разных куска, которые вызвали конфликт:
это не то же самое, что использовать инструмент слияния, так как инструмент слияния будет включать в себя все неконфликтные куски diff. Я считаю, что отвлекающий.
Совет Два
кто-то уже упоминал об этом, но понимание намерения за каждым отличием обычно очень полезно для понимания, откуда возник конфликт и как с ним справиться.
Это показывает все коммиты, которые коснулись этого файла между общим предком и двумя головами, которые вы объединяете. (Таким образом, он не включает коммиты, которые уже существуют в обеих ветвях до слияния.) Это поможет вам игнорировать diff hunks это явно не является фактором вашего нынешнего конфликта.
Совет Третий
Проверьте изменения с помощью автоматических инструментов.
если у вас есть автоматические тесты, запустите их. Если у вас есть Линта выполните это. Если это сборный проект, создайте его перед фиксацией и т. д. Во всех случаях, вам нужно сделать немного испытания, чтобы убедиться, что ваши изменения ничего не сломали. (Черт, даже слияние без конфликтов может нарушить рабочий код.)
Совет Четыре!—9—>
план вперед; общаться с коллегами.
планирование вперед и осознание того, над чем работают другие, может помочь предотвратить конфликты слияния и/или помочь разрешить их раньше-в то время как детали все еще свежи в памяти.
например, если вы знаете, что вы и другой человек работаете над разными рефакторингами, которые будут влиять на один и тот же набор файлов, вы должны заранее поговорить друг с другом и получить лучшее представление о том, какие типы файлов каждый из вас вносит изменения. Вы можете сэкономить значительное время и усилия, если будете проводить запланированные изменения последовательно, а не параллельно.
для основных рефакторингов, которые пересекают большую полосу кода, Вы должны настоятельно рассмотреть возможность работы последовательно: все перестают работать над этой областью кода, пока один человек выполняет полный рефакторинг.
если вы не можете работать последовательно (из-за давления времени, возможно), то сообщая об ожидаемых конфликтах слияния по крайней мере, поможет вам решить проблемы раньше, пока детали еще свежи в памяти. Например, если сотрудник совершает разрушительную серию коммитов в течение одной недели, вы можете выбрать слияние / ребазирование в этой ветви сотрудников один или два раза в день в течение этой недели. Таким образом, если вы найдете конфликты слияния/перебазирования, вы сможете решить их быстрее, чем если вы подождете несколько недель, чтобы объединить все вместе в один большой кусок.
Совет Пятый
если вы не уверены в слиянии, не форсируйте его.
слияние может показаться подавляющим, особенно когда есть много конфликтующих файлов и маркеры конфликтов охватывают сотни строк. Часто при оценке программных проектов мы не включаем достаточно времени для накладных расходов, таких как обработка узловатого слияния, поэтому кажется, что тратить несколько часов на разбор каждого конфликта-настоящее сопротивление.
в долгосрочной перспективе, планируя вперед и зная о том, что другие работают над лучшие инструменты для прогнозирования конфликтов слияния и подготовки к их правильному разрешению за меньшее время.
определите, какие файлы находятся в конфликте (Git должен сказать вам это).
откройте каждый файл и проверьте различия; Git разграничивает их. Надеюсь, будет очевидно, какую версию каждого блока сохранить. Возможно, вам придется обсудить это с другими разработчиками, которые совершили код.
проверьте ответы в вопросе переполнения стека прерывание слияния в Git, особенно ответ Чарльза Бейли который показывает, как просматривать различные версии файла с проблемами, например,
конфликты слияния происходят, когда изменения вносятся в файл одновременно. Вот как это решить.
git командной строки
вот простые шаги, Что делать, когда вы попадаете в конфликтное состояние:
разрешите конфликты отдельно для каждого файла одним из следующих подходов:
используйте GUI для решения конфликты: git mergetool (самый простой способ).
однако вы должны быть осторожны, так как удаленные изменения, что конфликты были сделаны по какой-то причине.
DiffMerge
Я успешно использовал DiffMerge который может визуально сравнивать и объединять файлы в Windows, macOS и Linux/Unix.
он графически может отображать изменения между 3 файлами и позволяет автоматическое слияние (когда это безопасно) и полный контроль над редактированием результирующего файла.
изображение: DiffMerge (скриншот в Linux)
просто загрузите его и запустите в репо as:
macOS
на macOS вы можете установить через:
и, вероятно (если не указано), вам нужна следующая дополнительная простая обертка, помещенная на вашем пути (например, /usr/bin ):
затем вы можете использовать следующие сочетания клавиш:
в качестве альтернативы вы можете использовать opendiff (часть инструментов Xcode), которая позволяет объединить два файла или каталога вместе, чтобы создать третий файл или каталог.
посмотреть Как Представлены Конфликты или, в Git, git merge документация, чтобы понять, что такое маркеры конфликтов слияния.
и как разрешить конфликты раздел объясняет, как разрешить конфликты:
, увидев конфликт, вы можете сделать две вещи:
разрешить конфликты. Git будет отмечать конфликты в рабочем дереве. Отредактируйте файлы в форму и git add их в индекс. Использовать git commit чтобы скрепить сделку.
вы можете работать через конфликт с рядом инструментов:
используйте mergetool. git mergetool для запуска графического mergetool, который будет поработайте над слиянием.
посмотрите на различия. git diff покажет трехсторонний diff, выделяя изменения от обоих HEAD и MERGE_HEAD версий.
сначала покажет различия для HEAD версия, а потом MERGE_HEAD версия.
смотреть на оригиналы. git show :1:filename показывает общего предка, git show :2:filename показывает HEAD версия, и git show :3:filename показывает MERGE_HEAD версия.
вы также можете прочитать о маркерах конфликтов слияния и о том, как их разрешить в Pro Git раздел книги Основные Конфликты Слияния.
на Emacs пользователи, которые хотят разрешить конфликты слияния полу-вручную:
показывает все файлы, требующие разрешения конфликтов.
открыть каждый из этих файлов по одному, или все сразу:
при посещении буфера, требующего редактирования в Emacs, введите
Это откроет три буфера (мой, их и выходной буфер). Перейдите, нажав » n «(следующая область), » p » (область предвидения). Нажмите ‘a’ и «b», чтобы скопировать мой или их регион в выходной буфер, соответственно. И / или редактировать выходной буфер напрямую.
когда закончите: нажмите «q». Emacs спрашивает вас, Хотите ли вы сохранить этот буфер: да. После завершения буфера отметьте его как разрешенный, запустив из териминала:
когда закончите со всеми буферами типа
для завершения слияния.
пожалуйста, выполните следующие действия, чтобы исправить конфликты слияния в Git:
проверьте состояние Git: git статус
получить набор патчей: git fetch (проверьте правильный патч из вашего git commit)
проверка локальной ветви (temp1 в моем примере здесь): git checkout-b temp1
запустите mergetool и проверьте конфликты и исправьте их. и проверьте изменения в удаленной ветви с вашей текущей веткой: git mergetool
проверьте состояние еще раз: git статус
удаление нежелательных файлов, локально созданных mergetool, обычно mergetool создает дополнительный файл с *.расширение ориг. Удалите этот файл, поскольку это просто дубликат и исправьте изменения локально и добавьте правильную версию своих файлов. git добавить #your_changed_correct_files
проверьте состояние еще раз: git статус
нажимаем в ветку master: git push (в ваш репозиторий Git)
просто, если вы хорошо знаете, что изменения в одном из репозиториев не важны, и хотите разрешить все изменения в пользу другого, используйте:
разрешить изменения в пользу хранилище или
разрешить изменения в пользу другое или главное хранилище.
и после завершения файла вам нужно будет сохранить и закрыть, чтобы открыть следующий.
Я либо хочу свою или их версию в полном объеме, либо хочу просмотреть отдельные изменения и решить для каждого из них.
полностью примите мою или их версию:
примите мою версию (локальную, нашу):
примите их версию (удаленную, их):
если вы хотите сделать для всех файлов конфликтов run:
просмотрите все изменения и примите их индивидуально
по умолчанию mergetool работает в командная строка. Как использовать командную строку mergetool должен быть отдельный вопрос.
вы также можете установить визуальный инструмент для этого, например, meld и работать
вы можете исправить конфликты слияния несколькими способами, как другие подробно.
Я думаю, что реальный ключ знает, как изменения протекают с локальными и удаленными репозиториями. Ключ к этому-понимание ветвей отслеживания. Я обнаружил, что я думаю о ветви отслеживания как о «недостающей части посередине» между моим локальным, фактическим каталогом файлов и удаленным, определенным как origin.
у меня лично вошло в привычку 2 вещи, чтобы помочь избежать этот.
a) все новые/измененные файлы добавляются, и это может включать некоторые нежелательные изменения.
b) вы не можете сначала просмотреть список файлов.
поэтому вместо этого я делаю:
[обновление-по прошествии времени я переключился больше на:
кроме того (и более уместно в вашей ситуации), я стараюсь избегать:
потому что pull подразумевает слияние, и если у вас есть изменения локально, которые вы не хотите объединять, вы можете легко получить объединенный код и / или объединить конфликты для кода, который не должен был быть слитый.