Как использовать visual studio code в качестве редактора по умолчанию для git mergetool

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

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

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

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

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

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

Продвинутые сценарии git merge

Параметр —no-commit

Бывают ситуации, когда история снимков (ряд команд commit) в ветке была сделана не очень осмысленно, то есть вы делали снимки состояний, которые не стоит сохранять в истории на всеобщем обозрении. Здесь то и пригодится параметр —no-commit. Он используется нечасто — только в том случае, если хочется уничтожить историю снимков ветки, так чтоб никто их никто никогда не увидел и к ним нельзя было вернуться.

Но сначала вернемся к вышеприведенным командам и рассмотрим, как работает merge без параметра:

git checkout master
git merge hotfix

Первая команда (checkout) переведет нас на ветку master. Это значит, что наша папка на диске физически заполнятся версиями файлов из ветки master

А команда merge:

• перенесет в master все изменения ветки hotfix. То есть содержимое текущей папки изменится с учетом залитых изменений
• и сделает commit (если нет нет конфликтов). То есть сделает снимок полученного состояния и занесет его  в историю. При этом история коммитов ветки hotfix будет сохранена и ее можно будет посмотреть.

Теперь рассмотрим, как работает команда merge с параметром.

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

git checkout master

Но в этот раз допустим, что снимки в ветке hotfix  были ненужными и мы хотим, чтоб их не было в истории. В этом случае надо добавить параметр —no-commit:

git merge --no-commit hotfix

Эта команда обновит текущие папки —  перенесет в них все изменения ветки hotfix, но финального снимка сделано не будет. Мы сможем еще кое-что поменять в файлах и потом выполнить команду commit самостоятельно. При этом в историю попадет только финальный снимок. Будет видно, что ветка hotfix слита с веткой master, и все. А снимки ветки hotfix видны не будут.

Параметр —squash

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

git checkout master

После выполнения команды:

git merge --squash hotfix

изменения  появятся в текущих папках ветки master, аналогично тому, как это было после выполнения предыдущей команды с аргументом —no-commit. При этом финального снимка (commit) так же не произойдет.

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

Параметр —no-ff

Параметр —no-ff запрещает перемотку.

ff означает fast forward, то есть перемотка.

Во-первых объясню, что такое перемотка. Она случается при слиянии, если в той ветке, от которой мы ответвились, не было снимков после нашего ответвления. Называется это перемоткой, потому что технически никакого нового снимка в этом случае делать не надо, выполняя слияние двух предков. Наш снимок считается последним, и на него просто перематывается текущий указатель. Смотрите пример.

На картинке мы ответвились от С и сделали снимки X и Y. После снимка C в ветке master никто ничего не делал, и при слиянии указатель просто переместится на снимок Y:

master: A - B - C
                 \
hotfix:           X - Y

Еще раз обратите внимание, что в ветке master после ответвления от С снимков не появилось, именно поэтому перемотка и возможна. С помощью аргумента —no-ff можно запретить перемотку, а именно: сделать при слиянии новый отдельный снимок, хоть в нем и нет технической необходимости

Сделаем это:

С помощью аргумента —no-ff можно запретить перемотку, а именно: сделать при слиянии новый отдельный снимок, хоть в нем и нет технической необходимости. Сделаем это:

git merge --no-ff hotfix

На картинке это выглядит так:

master: A - B - C   -  (M)
                 \     /
hotfix:           X - Y

Будет создан дополнительный снимок M и указатель переместится на него (хотя мог бы просто переместиться на Y, если б выполняли слияние без параметра —no-ff).

Когда именно стоит использовать параметр —no-ff сказать сложно — отчасти это вопрос вкуса

Некоторые любят делать отдельный снимок при любом важном слиянии

Далее рассмотрим git pull.

Графическое Слияние (GUI Merging)

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

Для использования графического инструмента (он должен быть установлен), после того как git пожаловался что есть конфликт, введите следующую команду:

Последует вопрос какой программой для слияния вы хотели бы воспользоваться, просто введите meld и нажмите Enter. Вот как окно программы может выглядеть (подразумевается опция merge.conflictstyle не была включена):

Несмотря на то что информация представлена бок о бок, она не отображает нужные фрагменты которые были в Listing 2. Мы не видим здесь фрагмента базы слияния (состояния (A)), что мы видим это файл roses.txt.LOCAL.2760.txt в левой колонке и файл roses.txt.REMOTE.2760.txt в правой колонке и файл посередине это неудачное слияние. Т.е. по сути нам представили состояния (B), (C) и несостоявшееся состояние (D), но состояние (A) отсутствует…

Правда отсутствует? Давайте проверим, в старом добром терминале:

Видим интересующий нас файл: roses.txt.BASE.2760.txt. Это и есть файл базы слияния. Теперь нам осталось всего лишь найти изменения внесённые в ветки master и beta, по отношению к базе. Мы можем сделать это двумя отдельными вызовами meld:

(Кто-то может подметить что было бы более разумно, поменять порядок аргументов в первом вызове, для того чтобы файл базы находился в левой колонке в обоих случаях, но именно такой порядок сохраняет подобие трёх-колоночного вида, при котором база остаётся по середине.) Результат выполнения — два окна как показано ниже:

При чтении первого окна справа налево и второго окна слева направо, становится ясно как день, какие изменения произошли в каждой ветке. Так как meld любезно подсветил все изменения, теперь практически не возможно пропустить даже мелко заметные правки (Кто-нибудь заметил добавление предлога “of” при просмотре текстового представления разрешения конфликта Listing 1 или даже Listing 2?)

Вооружившись этими знаниями, мы теперь можем вернуться к трёх-колоночному представлению и сделать изменения. Моя стратегия ручного слияния это взять весь текст из ветки с более весомыми изменениями (в данном случае master/REMOTE т.е. beta), и поверх него производить пошаговые правки, т.е. вносить изменения сделанные в другой ветке (master). Вот что получилось:

Просмотр файлов в Обозревателе решений в Visual Studio 2019

При клонировании репозитория или открытии локального репозитория Visual Studio переключается в этот контекст GIT, сохраняя и закрывая все ранее открытые решения и проекты. Обозреватель решений загружает папку в корне репозитория Git и проверяет дерево каталогов на наличие просматриваемых файлов. К ним относятся такие файлы, как CMakeLists.txt или файлы с расширением SLN.

Visual Studio настраивает представление в зависимости от файла, загруженного в обозреватель решений:

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

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

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

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
•    16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
•    24. Мердж-реквесты
• * 25. Форки

* платные уроки

список обновляется…

Назад к Базе (Back to Base)

Хитрость заключается в том, что Listing 1 не даёт вам полную информацию, необходимую для совершения корректного слияния. На самом деле, в процессе слияния участвуют четыре важных части информации (состояния), три из которых просто необходимы для успешного разрешения конфликта. В случае Listing 1, Git предоставил вам только два состояния.

Следующая диаграмма иллюстрирует эти четыре состояния:

Состояния (B) и (C) относятся к текущим положениям (head) веток master и beta соответственно, эти два состояния как раз таки и отражены в Listing 1. Состояние (D) это результат слияния, то что вы хотите получить/сгенерировать в конечном итоге (в большинстве случаев Git автоматически генерирует состояние (D)). Состояние (А) на самом верху, представляет собой базу (основу) слияния веток master и beta. База слияния (A) это последний общий предок веток master и beta, и пока предположим что это база слияния уникальна. Как мы увидим позже состояние (A) играет ключевую роль в разрешении конфликтов. На диаграмме я также отразил дельты 1 и 2, которые представляют изменения между состояниями (A)-(B), и (A)-(C) соответственно. Зная состояния (A), (B) и (C) дельты 1 и 2 могут быть легко получены (вычислены)

Обратите внимание, что дельты 1 и 2 могут состоять из более чем одного коммита. Но для наших целей будем считать что все дельты монолитны

Чтобы понять, как получить состояние (D), вы должны понимать что же операция слияния пытается сделать. Состояние (D) должно представлять собой сочетание изменений, внесённых в ветку master и beta соответственно. Т.е. другими словами сочетание дельт 1 и 2. Идея проста на поверхности и большую часть времени не требует вмешательства со стороны человека, за исключением особых случаев когда дельты затрагивают наслаиваемые (пересекающиеся) части файла. В такой ситуации вам требуется помочь машине сгенерировать результат (D), путём сравнения дельт 1 и 2.

git mergetool

Это должно проверить официальную документацию, Может открытьсяОфициальный документ GitДокумент очень хороший, а формат типографии очень удобно.

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

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

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

Предпосылка этих встроенных инструментов уже установлена, а каталог программного обеспечения установки помещен в переменные среды. В середине, если вы не поместите его в эту переменную, вам нужно пройти Параметры настроены, такие как я Установлены Корневой каталог может быть установлен。

Мы не нашли в доступных инструментах. Почему мы можем использовать это? Так как Команда также поддерживает пользовательские слияния для разрешения конфликтов, до тех пор, пока назначенный Вы можете позвонить, как Расследование， Ставить Как программное обеспечение, эквивалентное встроенному инструменту Merge.

Давайте посмотрим на значение этих 4 предложений:

Первое предложение Расскажи Инструмент по умолчанию настроенЕсли инструмент по умолчанию не указан, вам нужно написать Или же Но Это название нашего собственного, нет имени вообще, затем смотреть вниз.

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

Третье предложение, Установить как Указывает код возврата программного обеспечения доверия и определяет, является ли слияние успешным в соответствии с кодом возврата, если установлено значение Спросит, решаете ли вы конфликт после завершения слияния, установите его в Будет гораздо удобнее.

Четвертое предложение, Указан для удаления файлов резервных копий после завершения слияния.Этот файл позвонит Производить Файл резервного копирования автоматически удаляется после успешного слияния.

Считать

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

подводить итоги

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

А теперь всё вместе (All Together Now)

Надеюсь, вы найдёте этот трёх-окошечный метод разрешения конфликтов, таким же полезным каким нахожу его я. Но согласитесь что запускать новые вызовы meld вручную каждый раз при разрешении конфликтов, не очень то и удобно. Выход, это настроить git таким образом чтобы все три окна открывались автоматически при вызове команды git mergetool. Для этого можно создать выполняемый скрипт, который должен находится в переменной окружения PATH (например $HOME/bin/gitmerge), со следующим содержимым:

И добавьте следующее в ваш ~/.gitconfig файл:

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

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

Бонус от переводчика

Для тех кто пользуется tmux и n?vim, предлагаю следующий скрипт gitmerge:

Примечание: если вы не используете в своем ~/.tmux.conf, то вам надо поменять в двух последних строках на

Соответственно добавьте следующее в ваш

Воркфлоу разрешения конфликта будет выглядеть так:

Пока игнорируем вопрос (Was the merge successful [y/n]?) и переключаемся в сессию под названием gitmerge (сочетание TMUXPREFIX + s):

Видим наше трёх-оконное представление на одном экране. Цифрами обозначены сплиты (panes) tmux’a, буквами соответствующие состояния. Делаем правки для разрешения конфликта, т.е. редактируем состояние (D) и сохраняем. После этого возвращаемся обратно в исходную сессию tmux’a и подтверждаем что слияние произошло успешно.

git rebase master

Лично я предпочитаю и считаю более правильным делать сначала rebase master в ветке beta, и только после этого переключаться в master и делать git merge beta. В принципе воркфлоу не сильно отличается, за исключением трёх-оконного вида.

Переключаемся в сессию gitmerge

Обратите внимание, что состояния (B) и поменялись местами:

Рекомендую всем поиграться с примером репозитария хотя бы один раз, сделать разрешение конфликта по вышеописанной схеме. Лично я больше не гадаю а что же выбрать «Accept theirs» или «Accept yours».

5 ответов

Лучший ответ

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

В качестве обходного пути я настроил свой собственный вариант KDiff3 в качестве инструмента слияния:

Это очень похоже на то, что Git использует по умолчанию для KDiff3, но без флага .

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

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

35

Peter Mortensen
20 Июл 2018 в 23:17

Если проблема строго связана с автоматическим разрешением нежелательных конфликтов …

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

Patrizio Bertoni
20 Мар 2019 в 09:17

Вместо настройки mergetool, который вызывается только при конфликте, просто установите драйвер слияния с KDiff3:

Вы можете сделать этот драйвер глобальным, добавив . Но вам нужно добавить в свой репозиторий .gitattribute:

Peter Mortensen
20 Июл 2018 в 23:18

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

У меня сам был этот вопрос (особенно в отношении KDiff3), и ответ PiQuer помог мне частично, но он получил мне думать. Должен быть способ точно воспроизвести поведение Git по умолчанию для KDiff3, за исключением опции (из-за чего KDiff3 не отображает графический интерфейс).

Похоже, что источник команды по умолчанию для инструмента слияния KDiff3 находится в файле git / mergetools / kdiff3. Это похоже на сценарий оболочки, поэтому мы должны иметь возможность его точно скопировать! Помещение этого в одну строку, удаление и экранирование дает нам следующее:

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

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

Что касается пары других моментов в исходном вопросе:

• Параметр сообщает Git, является ли код выхода инструмента слияния правильным индикатором того, было ли слияние успешным. Это не повлияет на поведение инструмента слияния, а скорее на поведение Git после выхода из инструмента слияния. См. руководство для git-mergetool.
• Автоматическое разрешение, которое вы видите после ввода , выполняется самим инструментом слияния. просто вызывает внешний инструмент для версий файлов, которые необходимо объединить.

2

Peter Mortensen
20 Июл 2018 в 23:22

Комментарий Боба Эспонжи к принятому ответу отлично работал у меня с использованием KDiff3 0.9.98.

Добавьте в параметры командной строки, которые следует игнорировать: под

KDiff3 открывает диалоговое окно «Конфликты», в котором указывается Кол-во нерешенных конфликтов: 0 , но затем вы можете проверить / изменить объединенное состояние по мере необходимости.

Немного удобнее, чем настраивать собственный вариант, поскольку он будет работать по назначению, будь то из git mergetool, дерева исходных текстов или любого другого инструмента, использующего mergetool.

3

Pmpr
24 Апр 2020 в 21:36

Six.Git версия отката

Сначала определите версию отката, основываясь на истории отправки git

Запишите скопированный номер редакции выше, например: 4b91ea12de20cdf97eccb6bc9125bbc2fef79b17 Замечания: последние два шага, кажется, не в состоянии графически управлять интерфейсом в идеале, только в командной строке

Во-вторых, восстановить указанный хеш коммита git reset —hard resetVersionHash eg:git reset —hard 4b91ea12de20cdf97eccb6bc9125bbc2fef79b17

Наконец, текущая ветвь вынуждена зафиксировать удаленную git push -f origin currentBranch eg: push -f origin master

После выполнения трех указанных выше шагов локальный код и код удаленного доступа будут откатываться с 2017-8-12 18:45 до 2017-8-12 17:01.

Начало работы с Git в Visual Studio 2019

Мы подробно расскажем вам о том, как использовать новый интерфейс Git в Visual Studio. Однако если вы хотите сначала ознакомиться с кратким обзором, посмотрите следующее видео: Длительность видео: 05:27 мин.

Существует три способа начать использование Git в Visual Studio для повышения производительности:

• . Если у вас уже есть код и он не связан с Git, можно начать с создания нового репозитория Git.
• . Если код, с которым вы хотите работать, не находится на вашем компьютере, можно клонировать любые существующие удаленные репозитории.
• . Если у вас уже есть код на компьютере, его можно открыть с помощью пункта меню Файл > Открыть > Решение/проект (или Папка). Visual Studio автоматически определяет, имеется ли инициализированный репозиторий GIT.

Observação

Начиная с версии 16.8 Visual Studio 2019 включает полностью интегрированный интерфейс для работы с учетными записями GitHub. Теперь вы можете добавить в цепочку ключей учетные записи GitHub и GitHub Enterprise. Вы сможете добавлять и использовать их так же, как и учетные записи Майкрософт. Это позволит упростить доступ к ресурсам GitHub в Visual Studio. Дополнительные сведения см. на странице Работа с учетными записями GitHub в Visual Studio.

Dica

Если у вас нет учетной записи GitHub, можно начать с выполнения действий, описанных в разделе Создание учетной записи GitHub для использования с Visual Studio.

Задание 9. Hot Rebase

1. Создай ветку и перейди на нее.
   Используй сочетание , чтобы вызвать диалог создания ветки: так быстрее!

2. Создай файл со следующим содержимым:

1. Закоммить изменения с сообщением .
   Воспользуйся сочетанием , чтобы открыть окно коммита: так быстрее!

2. Замени содержимое на следующее:

1. Закоммить изменения с сообщением . Используй .

2. Перейди на ветку . Используй .

3. Замени содержимое на следующее:

Закоммить изменения с сообщением . Используй .

Открой в главном меню пункт

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

Установи тег на коммит, на который ссылается

Перейди на ветку

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

Первый коммит успешно скопирован, а вот по понятным причинам порождает конфликты.
Нажми кнопку , чтобы разрешить конфликты в VS Code.
Несмотря на то, что файлы были созданы в разных ветках, Git видит,
что первые строчки совпадают и по ним конфликта нет
А вот оставшиеся строчки конфликтуют.
Так как в ветке был правильный текст, нажми ,
затем сохрани изменения, закрой файл в VS Code (важно!), перейди в Git Extensions и нажми .
Раз оба коммита были успешно скопированы, rebase на этом будет закончен.

Обрати внимание, что в результате rebase были созданы коммиты и .
Хоть они похожи на исходные, все же это новые коммиты с новыми ревизиями.
Ветка была перемещена и теперь ссылается на новый коммит.
Старые коммиты остались в репозитории и на последний из них все еще ссылается тег .

Перейди на ветку и влей в нее изменения из. Влитие получится в режиме fast-forward.

Теперь история коммитов должна выглядеть так:

5 ответов

Попытка:

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

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

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

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

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

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

Шаг 2 : Выполненный после команды на Шаге 3 терминала

: Вы будете видеть, что vimdiff отображается в следующем формате

, который Эти 4 представления

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

информация о vimdiff навигации здесь и здесь

Шаг 4 . Вы могли отредактировать представление MERGED следующий путь

, Если Вы хотите получить изменения от УДАЛЕННОГО

, Если Вы хотите получить изменения от ОСНОВЫ

, Если Вы хотите получить изменения от ЛОКАЛЬНОГО

Шаг 5 . Сохраните, Выход, Фиксация и Вымойтесь

, сохраняют и выходят от vi

, Удаляют дополнительные файлы (например, *.orig) созданный различным инструментом.

ответ дан Fozoro 15 May 2019 в 21:21

При создании частых маленьких фиксаций то запустите путем рассмотрения комментариев фиксации с . Тогда покажет Вам конфликты.

Для конфликтов, которые включают больше, чем несколько строк, легче видеть то, что продолжается во внешнем инструменте GUI. Мне нравится opendiff — Мерзавец также поддерживает vimdiff, gvimdiff, kdiff3, tkdiff, комбинация, xxdiff, появитесь из поля, и можно установить других: установит Ваш выбранный инструмент и затем после того, как неудавшееся слияние покажет Вам diffs в контексте.

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

ответ дан Peter Mortensen 15 May 2019 в 21:21

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

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

3. , Как только Вы разрешили конфликт в файле .

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

ответ дан davetron5000 15 May 2019 в 21:21

Проверьте ответы в вопросе о Переполнении стека Прерывание слияния в Мерзавце , особенно , который показывает, как просмотреть различные версии файла с проблемами, например,

ответ дан Community 15 May 2019 в 21:21

Я использую Визуальный Код Microsoft для разрешения конфликтов. Его очень простое для использования. Я сохраняю свой проект открытым в рабочей области. Это обнаруживает и выделяет конфликты, кроме того, дайте опции GUI выбрать безотносительно изменения, я хочу удержаться от ГОЛОВЫ или поступления.

ответ дан Ammar Mujeeb 4 October 2019 в 06:59

Другие вопросы по тегам:

Сценарии

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

git config

Сначала вам нужно знать Роль используется для настройки Плюс Экспресс-регулировка Настройте, если вы не добавите, отрегулируйте текущую библиотеку Конфигурация. Глобальная конфигурация в Windows обычноЕсли вы использовали этоКак правило, будет реализованПравильно, эти команды корректируются Настроить, откройте это ты увидишь

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