Как отменить слияние веток git visual studio
Мы всегда готовы подчеркивать бесчисленные возможности, которые предлагает Git, и эта статья не станет исключением. Git известен своей потрясающей способностью отменять практически любые действия! Наверняка на память вам уже приходят тысячи печальных случаев, когда вы делали объединение, а потом понимали, что в ваши планы оно не входило. Даже если вам кажется, что ошибочное объединение— это величайшая неудача всей вашей жизни, сделайте глубокий вдох и дочитайте статью до конца.
Один из самых распространенных вопросов в сообществе Git звучит так: “Как откатить git add перед коммитом?” Вы можете отменить действия над конкретным файлом или все внесенные изменения.
Решение, которое потребуется для этого, весьма простое. Чтобы откатить один файл, просто вызовите команду git reset :
Для отмены всех изменений запустите следующее:
Необходимость в откате становится неизбежной, если вы сделали коммит слишком рано и забыли добавить еще несколько файлов. В подобных случаях используется команда amend , чтобы внести изменения, зафиксировать их и сделать коммит снова.
Здесь на помощь приходит еще одна команда класса “отмена”: git revert . Начнем с того, что переключимся на мастер-ветку, используя команду git checkout :
Следующий шаг — запустить команду git log , чтобы получить ID сделанного объединения:
Затем вернитесь к упомянутому коммиту, выполнив следующее:
Используя -m 1 , вы даете Git указание: вернуться к первому родительскому элементу мастер-ветки, куда был совершен коммит объединения. Например, использование -m 2 сказало бы Git вернуться к первому родительскому элементу ветки, откуда пришел запрос на объединение.
Git также предлагает возможность предварительного просмотра, если вы хотите увидеть, что произойдет при объединении веток.
Предлагаем суперкороткий способ отменить команду git reset:
Следом можно запустить команду git reflog , чтобы просмотреть журнал всех обновлений (т.е. переключение веток, сброс, коммит, объединение).
Существует несколько методов для отмены git commit . Давайте рассмотрим их по очереди.
Команду git reset можно использовать для отмены внесенных изменений:
Вместо ~x введите число. Например, если вы укажете ~4 , то команда повлияет на четвертый снизу коммит. Если вы не укажете никакое конкретно число, git reset — soft HEAD применится к последнему коммиту.
Когда вы используете команду git reset — soft HEAD , то просто отменяете последний коммит, при этом внесенные изменения останутся в вашем рабочем дереве и в вашем индексе. Поэтому git commit создаст в будущем коммит с теми же самыми изменениями, которые вы “обнулили” перед этим.
Другой метод — это команда git revert HEAD~x ( git reset — hard commit hash ), которая отменяет изменения, указанные последним коммитом в HEAD , и создает новый с возвращенными изменениями:
Этот метод лучше всего работает в случае с общими публичными репозиториями.
Допустим, вы выполнили команду git rebase в локальной ветке git и отправили ее в удаленную ветку. Следом вы поняли, что это не отвечает вашим ожиданиям, и захотели отменить сделанное.
Самый простой способ — найти главный коммит вашей ветки, запустив команду:
Следом необходимо установить туда текущую ветку, воспользовавшись git reset .
В данном случае старым коммитом был HEAD5 .
Вот и все о том, как вы можете отменить наиболее часто используемые команды в Git. Хоть никакой традиционной команды отмены и нет, другие команды git могут помочь вам откатить то, что вы могли сделать по ошибке.
Team Explorer Visual Studio позволяет выполнять наиболее распространенные задачи Git, необходимые для повседневной работы. В меню Visual Studio "Вид" откройте Team Explorer или нажмите клавиши CTRL+, CTRL+M.
Team Explorer и командная строка Git отлично работают вместе. При внесении обновлений и выполнении команд с помощью одного интерфейса эти изменения будут отражены в другом.
Инструкции по установке Git доступны, если на компьютере не установлен Git.
Windows пользователей: если вы не используете Visual Studio, установите Git для Windows, чтобы настроить диспетчер учетных данных Git. Диспетчер учетных данных упрощает проверку подлинности с помощью Azure Repos.
В Visual Studio откройте командную строку в репозитории из представления Подключение Team Explorer. Щелкните правой кнопкой мыши локальный репозиторий и выберите команду "Открыть командную строку".
Для выполнения некоторых команд требуется наличие определенных разрешений Git в Azure Repos.
Repos
Разделы справки?
Командная строка Git
Visual Studio
Создание репозитория в новой папке
git init Foldername
Создание репозитория с кодом в существующей папке
git init Foldername
git add --all
git commit -m "Initial commit"
Создайте репозиторий из командной строки, а затем откройте представление Подключение Team Explorer и выберите "Добавить в локальные репозитории Git".
Создание репозитория из существующего решения Visual Studio
git init Foldername
cd Foldername
git add --all
git commit -m "Initial commit"
Откройте решение и выберите " Опубликовать " ( ) в строке состояния в правом нижнем углу.
Создание нового репозитория в Project
В Интернете выберите Repos (или код, если вы еще не включили новую предварительную версию навигации), а затем щелкните раскрывающийся список рядом с текущим именем репозитория и выберите новый репозиторий.
Клонирование репозитория в локальную папку
git clone URLfoldername
Выберите "Клонировать" в разделе "Локальные репозитории Git" в представлении Подключение Team Explorer
Клонирование репозитория в Project
git clone URLfoldername
Откройте представление Подключение в Team Explorer и щелкните правой кнопкой мыши репозиторий Git в Project под именем учетной записи. Выберите "Клонировать" .
Добавление существующего репозитория в Visual Studio
Откройте файл решения в Visual Studio (это автоматически добавит репозиторий в Team Explorer) или выберите "Добавить в локальные репозитории Git" в представлении Подключение
Удалите репозиторий и журнал Git, но сохраните текущую версию файлов.
Удалите скрытую папку GIT, созданную в корне репозитория.
Удалите скрытую папку Git, созданную в корневом каталоге репозитория, из обозревателя Windows или командной строки.
Удаление локального репозитория и всех файлов
Удаление папки, содержащей репозиторий, из файловой системы компьютера
Закройте все открытые решения с помощью файлов в репозитории, а затем удалите папку, содержащую репозиторий, из файловой системы компьютера.
Удаление репозитория в Project
Добавление удаленного приложения
git remote add nameurl
Откройте репозиторий с помощью представления Подключение в Team Explorer, а затем откройте представление Параметры в Team Explorer. Выберите Параметры репозитория и выберите "Добавить" в разделе "Удаленные"
Обновление удаленного приложения
git remote set-url nameurl
Откройте репозиторий с помощью представления Подключение в Team Explorer, а затем откройте представление Параметры в Team Explorer. Выберите Параметры репозитория и выберите "Изменить" в разделе "Удаленные"
Дополнительные сведения см. в следующих ресурсах:
Ветви
Разделы справки?
Командная строка Git
Visual Studio
git branch branchname
Откройте представление "Ветви " в Team Explorer, а затем щелкните правой кнопкой мыши ветвь и выберите "Создать локальную ветвь" из.
Переключение на другую ветвь
git checkout branchname
Откройте представление "Ветви " в Team Explorer, а затем дважды щелкните локальную ветвь. Кроме того, щелкните имя текущей ветви в строке состояния и выберите другую ветвь.
Создание и переключение на новую ветвь
git checkout -b branchname
Откройте представление "Ветви " в Team Explorer, а затем щелкните правой кнопкой мыши ветвь и выберите "Создать локальную ветвь" из.
Удаление локальной ветви
git branch -d branchname
Откройте представление "Ветви " в Team Explorer, а затем щелкните правой кнопкой мыши ветвь и выберите команду "Удалить". Вы должны быть извлечены в другую ветвь, отличную от ветви, которую вы хотите удалить.
Удаление удаленной ветви
git push origin --delete branchname
Откройте представление "Ветви " в Team Explorer, разверните удаленный узел с ветвью, которую требуется удалить. Щелкните правой кнопкой мыши удаленный элемент и выберите "Удалить ветвь из удаленного"
Блокировка ветви, предотвращение обновлений для нее
В Интернете выберите вкладку "Ветви " во время просмотра репозитория. Выберите . рядом с ветвью, которую нужно заблокировать, и нажмите кнопку "Заблокировать". Разблокируйте ветвь с помощью разблокировки.
Настройка ветви по умолчанию в репозитории Azure DevOps
Щелкните значок параметров в Интернете ( ), а затем перейдите на вкладку "Управление версиями ". Выберите репозиторий Git, а затем щелкните . рядом с именем ветви и выберите "Задать в качестве ветви по умолчанию".
Настройка ветви сравнения для запросов на вытягивание в репозитории Azure DevOps
В Интернете выберите вкладку "Ветви " во время просмотра репозитория. Выберите . рядом с ветвью, которую нужно заблокировать, и нажмите кнопку "Сравнить ветвь".
Дополнительные сведения см. в следующих ресурсах:
Фиксации
Разделы справки?
Командная строка Git
Visual Studio
Создание новой фиксации
git commit -m "message"
Изменение последней фиксации с промежуточными изменениями
Откройте представление "Изменения" в Team Explorer, настроите изменения, а затем выберите "Изменить предыдущую фиксацию " в раскрывающемся списке "Действия ".
Этап всех изменений файлов
Откройте представление "Изменения " в Team Explorer. Щелкните значок в списке +изменений , чтобы подготовить все изменения для следующей фиксации.
Этап изменения определенного файла
git add имя_файла
Откройте представление "Изменения " в Team Explorer. Чтобы изменить этап, щелкните правой кнопкой мыши измененный файл и выберите "Этап".
Просмотр незатегированных изменений
git status --untracked
Откройте представление "Изменения " в Team Explorer. Незапланированные изменения перечислены в разделе "Изменения ".
git rm имя_файла
git commit -m "filename"
Удалите файл с помощью Обозреватель решений, командной строки или любых других средств. Щелкните правой кнопкой мыши удаленный файл в представлении изменений Team Explorer и выберите "Этап". Выберите "Зафиксировать промежуточно", чтобы зафиксировать удаление.
git mv имя_файла
git commit -m " Перемещено имя файла"
Переместите файл из одного расположения в другое в репозитории с помощью Обозреватель решений, командной строки или других средств. Щелкните правой кнопкой мыши перемещенный файл в представлении изменений Team Explorer и выберите "Этап ". Выберите "Зафиксировать промежуточно", чтобы зафиксировать перемещение.
git tag -a имя тега -m "description"
Откройте представление "Изменения" в Team Explorer, а затем выберите "Просмотреть журнал. " в раскрывающемся списке "Действие ". Найдите фиксацию в представлении журнала, а затем щелкните правой кнопкой мыши и выберите команду "Создать тег".
Дополнительные сведения см. в разделе "Сохранение работы с фиксациями".
Сравнение файлов и версий
Разделы справки?
Командная строка Git
Visual Studio
Сравнение текущего содержимого одного файла и содержимого последней фиксации
git diff HEAD имя_файла
Щелкните правой кнопкой мыши изменение в представлении "Изменения " в Team Explorer и выберите "Сравнить с неизмененных".
Сравнение текущей версии с ветвью
git diff branchname
Щелкните правой кнопкой мыши файл в Обозреватель решений и выберите "Просмотреть журнал. ", а затем выберите последнюю фиксацию в текущей ветви и последнюю фиксацию в удаленной ветви. Щелкните правой кнопкой мыши и выберите " Сравнить"
Сравнение изменений между двумя ветвями
git diff branchname1branchname2
Щелкните правой кнопкой мыши файл в Обозреватель решений и выберите "Просмотреть журнал. ", а затем выберите последние фиксации для обеих ветвей. Щелкните правой кнопкой мыши и выберите " Сравнить"
Синхронизация изменений
Разделы справки?
Командная строка Git
Visual Studio
Скачивание новых ветвей и фиксаций из удаленного репозитория, но не слияние их с локальными ветвями
Откройте представление синхронизации из Team Explorer и выберите "Выборка".
Слияние обновлений из удаленного репозитория в локальный репозиторий
git pull remotebranchname
Во время работы с ветвью в локальном репозитории откройте представление "Синхронизация " в Team Explorer, а затем выберите "Вытягивание".
Публикация локальной ветви в удаленном репозитории
git push -u remotebranchname
Откройте представление синхронизации в Team Explorer и выберите " Опубликовать " в разделе "Исходящие фиксации".
Синхронизация локальной ветви с удаленной ветвью, отправка локальных изменений и извлечение удаленных
git pull remotebranchname
Отправка git -u remotebranchname
Откройте представление синхронизации в Team Explorer. Выберите Синхронизация.
git push --force -u origin remote_branchname
Работа из командной строки
Дополнительные сведения см. в следующих ресурсах:
Слияние и повторная база
Разделы справки?
Командная строка Git
Visual Studio
Слияние ветви с текущей ветвью
git merge branchname
В представлении "Ветви Team Explorer" щелкните правой кнопкой мыши ветвь, которую нужно объединить, и выберите "Объединить из". Проверьте набор параметров и нажмите кнопку "Объединить".
Слияние удаленной ветви с текущей ветвью
git pull origin branchname
В представлении "Ветви Team Explorer" щелкните правой кнопкой мыши удаленную ветвь, которую нужно объединить, и выберите "Объединить из". Проверьте набор параметров и нажмите кнопку "Объединить".
Перебазируйте текущую ветвь в журнал другой ветви
git rebase branchname
В представлении "Ветви Team Explorer" щелкните правой кнопкой мыши ветвь, на которую вы хотите изменить текущую ветвь, и выберите "Перебазировать на.
Выполните интерактивную перебазу последних n фиксаций
git rebase -i HEAD ~n (Linux и macOS)
git rebase -i "HEAD ^n" (Windows)
Выбор фиксации в текущей ветви
git cherry-pick commitID
Откройте представление "Изменения" в Team Explorer, а затем выберите "Просмотреть журнал" в раскрывающемся списке "Действие ". Найдите фиксацию в представлении журнала, а затем щелкните правой кнопкой мыши и выберите "Черри-выбрать"
Дополнительные сведения см. в следующих ресурсах:
Отменить
Если вы не опытный пользователь Git, будьте осторожны при использовании reset команды. Подробнее
Разделы справки?
Командная строка Git
Visual Studio
Отмена всех изменений и откат к последней фиксации
git reset --hard HEAD
Откройте представление изменений в Team Explorer. Выберите **Действия и выберите "Просмотреть журнал " в раскрывающемся списке. Щелкните правой кнопкой мыши фиксацию, в которой находится ветвь, и выберите "Сбросить и удалить изменения".
Отмена промежуточного хранения файлов, но сохранение изменений в файлах
git reset --mixed HEAD
Откройте представление изменений в Team Explorer. Выберите **Действия и выберите "Просмотреть журнал " в раскрывающемся списке. Щелкните правой кнопкой мыши фиксацию, в которой находится ветвь, и выберите "Сбросить и сохранить изменения".
Удаление неотслеченных файлов
В представлении "Изменения" в Team Explorer щелкните правой кнопкой мыши файлы, которые нужно удалить в разделе "Изменения ", помеченные как [добавить], и выберите "Удалить".
Сброс локальной ветви до последней фиксации в удаленной ветви
git reset --hard Удаленного/branchname
(например, git reset --hard origin/main )
Щелкните правой кнопкой мыши ветвь в представлении "Ветви Team Explorer" и выберите "Сброс и удаление изменений".
Отмена фиксации, отправленной в удаленный репозиторий
git revert commitID
Откройте представление изменений в Team Explorer. Выберите **Действия и выберите "Просмотреть журнал " в раскрывающемся списке. Щелкните правой кнопкой мыши фиксацию, чтобы вернуться, и выберите "Вернуть".
При отмене изменений в Git сначала определите тип изменений, которые требуется отменить. Эти изменения делятся на три категории:
- Отмена незафиксированных изменений в файле, приведя файл обратно к версии в последней фиксации.
- Сбросьте локальную ветвь до предыдущей фиксации.
- Отмена изменений, отправленных в удаленную ветвь и доступ к которой предоставлен другим пользователям.
Из этого руководства вы узнаете, как выполнить следующие задачи:
- Отмена незафиксированных изменений в одном файле
- Отмена изменений в общих фиксациях
- Сброс ветви до предыдущего состояния
Отмена незафиксированных изменений в одном файле
Восстановите содержимое файла обратно в известную хорошую версию, удалив нежелательные изменения.
Эти команды перезаписывают существующие изменения файла. Если вы считаете, что эти изменения могут потребоваться позже, рассмотрите возможность их скрытия .
Visual Studio 2019 версии 16.8 и более поздних версий предоставляют новое меню Git для управления рабочим процессом Git с меньшим переключением контекста, чем Team Explorer. Процедуры, описанные в этой статье на вкладке Visual Studio 2019, содержат сведения об использовании интерфейса Git, а также Team Explorer. Дополнительные сведения см. в статье о параллельном сравнении Git и Team Explorer.
Visual Studio 2015 & 2017 г.
Откройте представление изменений в Team Explorer.
В разделе "Изменения" найдите файл, который требуется восстановить до предыдущей версии. Если изменение выполняется поэтапно, удалите его из раздела "Промежуточные изменения ", щелкнув правой кнопкой мыши и выбрав "Отменить этап".
Щелкните этот файл правой кнопкой мыши и выберите команду "Отменить изменения".
Вы можете использовать checkout команду и присвоить ей имя файла для изменения. Используйте подстановочные знаки для отмены изменений в нескольких файлах.
Вы можете вернуть файл к версии в определенной фиксации, указав идентификатор фиксации:
Это отличается от предыдущего использования команды, используемой checkout для переключения на другую ветвь. Git сообщит вам, изменяет ли он файл или переключается между ветвями в выходных данных, и жалуется, если это не ясно, какой из них вы пытаетесь сделать.
Отмена изменений в общих фиксациях
Используется revert для отмены изменений, внесенных в фиксации, отправленных в общие ветви. Команда revert создает новую фиксацию, которая отменяет изменения предыдущей фиксации. Журнал не переписывается в , revert что делает его безопасным для использования при работе с другими пользователями.
Visual Studio 2019 версии 16.8 и более поздних версий предоставляют новое меню Git для управления рабочим процессом Git с меньшим переключением контекста, чем Team Explorer. Процедуры, описанные в этой статье на вкладке Visual Studio 2019, содержат сведения об использовании интерфейса Git, а также Team Explorer. Дополнительные сведения см. в статье о параллельном сравнении Git и Team Explorer.
Откройте представление изменений в Team Explorer. Выберите "Действия" и выберите "Просмотреть журнал " в раскрывающемся списке. В появившемся окне журнала щелкните правой кнопкой мыши фиксацию, чтобы отменить и выберите "Вернуться " в контекстном меню.
Эти команды отменят изменения, внесенные в фиксацию 8437fbafbaf, и создадут новую фиксацию в ветви. Исходная фиксация commit_id по-прежнему находится в журнале Git. Revert является гибким, но для этого требуется журнал ветвей и идентификаторы фиксации. Просмотрите журнал , чтобы найти фиксации, которые вы хотите вернуть.
Сброс ветви до предыдущего состояния
Используется reset для возврата ветви в локальном репозитории к содержимому предыдущей фиксации. Наиболее распространенное использование reset команды заключается в том, чтобы просто отменить все измененные файлы с момента последней фиксации и вернуть файлы в состояние, в которое они находились в последней фиксации.
Не используйте reset ветвях, к которым предоставлен доступ другим пользователям. Вместо этого используйте возврат .
Откройте представление изменений в Team Explorer.
Выберите "Действия" и выберите "Просмотреть журнал " в раскрывающемся списке.
В появившемся окне журнала щелкните правой кнопкой мыши фиксацию, чтобы сбросить репозиторий и выберите "Сбросить" в контекстном меню.
Часть --hard команды сообщает Git, что Git сбрасывает файлы в состояние предыдущей фиксации и отменяет все промежуточные изменения. Аргумент HEAD сообщает Git о сбросе локального репозитория до последней фиксации. Если вы хотите сбросить репозиторий на другую фиксацию, укажите идентификатор вместо HEAD.
Это reset влияет на все файлы в текущей ветви в репозитории, а не только на файлы в текущем каталоге. Reset Отменяет только изменения, которые еще не были зафиксированы.
При слиянии или перебазировании вы сообщаете Git интегрировать изменения, внесенные в одну ветвь, с изменениями, внесенными в другую. Часто Git автоматически завершает слияние или повторное создание базы без помощи. Однако если Git обнаруживает, что изменения, внесенные в одну ветвь, конфликтуют с изменением, сделанным в другой, он предложит устранить конфликт. Конфликт слияния может возникать, когда объединенные ветви изменяют одну и ту же строку файла по-разному или когда одна ветвь изменяет файл, а другая ветвь удаляет ее. Процесс разрешения конфликтов слиянием применим как к слиянию, так и к повторной базе Git.
Конфликты слияния можно разрешить в Visual Studio или с помощью командной строки и любого текстового редактора.
Общие сведения о рабочем процессе Git см. в Azure Repos руководстве по Git.
В этой статье приведены процедуры для следующих задач:
- Общие сведения о конфликтах слиянием
- Разрешение конфликтов слияния
Общие сведения о конфликтах слиянием
Слияние или перебаза Git интегрирует фиксации из исходной ветви в текущую локальную ветвь (целевая ветвь). Слияние Git выполняет либо быстрый переадресацию, либо слияние без быстрого переадресации. Слияние без быстрого переадресации также называется трехсторонным слиянием или истинным слиянием. Перебаза Git — это еще один тип слияния. Эти типы слияния показаны на следующей схеме.
Для слияния Git, если подсказка целевой ветви существует в исходной ветви, тип слияния по умолчанию будет быстрым слиянием. В противном случае тип слияния по умолчанию не будет быстрым слиянием.
Быстрое слияние никогда не может иметь конфликт слияния, так как Git не будет применять быстрое слияние, если чаевые целевой ветви расходились от исходной ветви. По умолчанию Git по возможности использует быстрое слияние. Например, Git будет применять быстрое слияние в локальной ветви, которую вы обновляете только путем извлечения из удаленной ветви-аналога.
Слияние без быстрого переадресации создает новую целевую ветвь "фиксация слияния", которая интегрирует изменения исходной ветви с изменениями целевой ветви. Применимые изменения — это изменения, внесенные после последней фиксации, которая является общей для обеих ветвей. На предыдущей схеме фиксация C является последней общей фиксацией в обеих ветвях. Если любое изменение исходной ветви конфликтует с любым изменением целевой ветви, Git предложит устранить конфликт слияния. Фиксация слияния (L) содержит изменения интегрированной исходной ветви и целевой ветви. Подсказки исходной и целевой ветви (K и E) являются родителями фиксации слияния. В журнале фиксаций ветви фиксация слияния является полезным маркером для операции слияния и четко показывает, какие ветви были объединены.
Git rebase перебазирует журнал фиксаций целевой ветви, чтобы он содержал все фиксации исходной ветви, а затем все фиксации целевой ветви с момента последней общей фиксации. На предыдущей схеме фиксация C является последней общей фиксацией в обеих ветвях. Другой способ просмотра заключается в том, что перебаза воспроизводит изменения в целевой ветви поверх журнала исходной ветви. Если любое изменение исходной ветви конфликтует с любым изменением целевой ветви, Git предложит устранить конфликт слияния. Как и при быстром слиянии, перебаза не создает фиксацию слияния. В частности, перебаза изменяет последовательность фиксаций существующей целевой ветви, что не относится к другим стратегиям слияния. На предыдущей схеме фиксация K' содержит те же изменения, что и K, но имеет новый идентификатор фиксации, так как он ссылается обратно на фиксацию E вместо C.
Слияние и перебаза Git изменяют только целевую ветвь. Исходная ветвь остается неизменной. При возникновении одного или нескольких конфликтов слиянием их необходимо разрешить для завершения слияния или повторной базы. Кроме того, можно отменить операцию слияния или перебазы и вернуть целевую ветвь в предыдущее состояние.
Дополнительные сведения о вариантах слияния и стратегиях см. в справочном руководстве по Git и стратегиях слияния Git.
Когда следует разрешать конфликты слиянием
Слияние Git и перебаза Git широко используются в рабочем процессе Git. При работе с локальной функцией или ветвью исправлений часто рекомендуется:
- main Сохраняйте локальную ветвь в актуальном состоянии с удаленным аналогом, периодически извлекая и объединяя удаленные фиксации.
- Интеграция обновлений локальной main ветви в локальную ветвь компонентов с помощью повторной базы или слияния.
- Создайте резервную копию своей работы в локальной ветви компонентов, перенастроив ее в соответствующую удаленную ветвь.
- После завершения функции создайте запрос на вытягивание , чтобы объединить удаленную ветвь компонентов в удаленную main ветвь.
Часто интегрируя удаленные изменения в локальный репозиторий, вы можете оставаться в курсе недавних работ другими пользователями и быстро устранять возникающие конфликты слияния.
Разрешение конфликтов слияния
Процесс устранения конфликтов слиянием применим как к слиянию Git, так и к перебазе Git. Хотя в следующих шагах описано, как разрешать конфликты слиянием во время слияния, можно аналогичным образом разрешать конфликты слиянием во время перебазы.
Если исходная ветвь является ветвью удаленного отслеживания , убедитесь, что ветвь обновлена, запустив получение Git перед слиянием. Или выполните команду извлечения Git, которая объединяет получение Git с слиянием Git.
Visual Studio 2019 версии 16.8 и более поздних версий предоставляет возможности управления версиями Git, сохраняя пользовательский интерфейс Team Explorer Git. Чтобы использовать Team Explorer, снимите флажок ToolsOptionsPreview> >FeaturesNew>Git в строке меню. Функции Git можно использовать из любого интерфейса взаимозаменяемо. Ниже мы предоставляем параллельное сравнение способов разрешения конфликтов слияния во время слияния Git.
Visual Studio Git
- В области "Ветви" окна репозитория Git проверьте целевую ветвь. Затем щелкните правой кнопкой мыши исходную ветвь и выберите "Объединить >".
- Visual Studio уведомит вас, если Git остановил слияние из-за конфликтов. В этом случае можно либо устранить конфликты, либо отменить слияние и вернуться в состояние перед слиянием. В разделе "Отменяемые изменения" в окне изменений Git перечислены файлы с конфликтами слияния. Для файла с конфликтами слиянием в его содержимом дважды щелкните файл, чтобы открыть его в редакторе слиянием.
- Для файла, который был изменен в одной ветви и удален в другой, щелкните правой кнопкой мыши файл и выберите нужное действие ветви.
Обозреватель Team Explorer в Visual Studio
- В представлении "Ветви" Team Explorer проверьте целевую ветвь. Затем щелкните правой кнопкой мыши исходную ветвь и выберите команду "Объединить из".
- Проверьте параметры слияния и нажмите кнопку "Объединить".
- Visual Studio уведомит вас, если Git остановил слияние из-за конфликтов. В этом случае можно либо устранить конфликты, либо отменить слияние и вернуться в состояние перед слиянием. Чтобы устранить конфликты, выберите "Конфликты ", чтобы открыть представление "Разрешить конфликты ".
- В представлении "Разрешить конфликты " перечислены файлы с конфликтами слияния. Выберите файл из списка, чтобы просмотреть параметры разрешения для этого файла.
- Для файла с конфликтами слиянием в его содержимом нажмите кнопку "Объединить ", чтобы открыть его в редакторе слиянием.
- Для файла, который был изменен в одной ветви и удален в другой, выберите нужное действие ветви.
- В представлении "Разрешить конфликты " нажмите кнопку "Зафиксировать слияние " после разрешения всех конфликтов слияния для всех файлов.
Вы будете проинформированы о конфликтах слияния при извлечении изменений или попытке слияния двух ветвей.
Появится уведомление о конфликте. Выберите ссылку "Конфликты ", чтобы начать разрешение конфликтов файлов.
Откроется список файлов с конфликтами. Если выбрать файл, вы можете принять изменения в исходной ветви, с помощью кнопки "Взять источник " или принять изменения в ветви, в которую выполняется слияние с помощью Keep Target. Вы можете вручную объединить изменения, нажав кнопку "Объединить", а затем введя изменения непосредственно в средство слияния, указанное в параметрах Git.
Установите флажки рядом с строками, измененными для полного выбора между удаленными и локальными изменениями, или измените результаты непосредственно в редакторе результатов в редакторе "Источник " и " Целевой " в представлении дифф.
После внесения изменений нажмите кнопку "Принять слияние". Повторите это для всех конфликтующих файлов.
Откройте представление изменений в Team Explorer и зафиксируйте изменения, чтобы создать фиксацию слияния и устранить конфликт.
Сравните конфликтующие фиксации и различия между общей историей с параметрами в средстве слияния Visual Studio.
Прежде чем объединить исходную ветвь с целевой, проверьте целевую ветвь. Затем используйте команду слияния Git, чтобы объединить исходную ветвь в текущую локальную ветвь (целевая ветвь). Чтобы объединить несколько исходных ветвей в целевую ветвь, разделите имена исходных ветвей пробелами.
Можно также использовать git switch для переключения на ветвь.
В некоторых сценариях команда слияния Git завершится ошибкой или остановится до завершения.
Для текущей операции слияния можно:
- Выполните команду git status , чтобы получить список файлов с конфликтами слияния.
- Выполните git log --merge команду, чтобы получить список конфликтующих фиксаций в исходной и целевой ветвях.
Разрешение конфликтов содержимого файла
Откройте файл в любом редакторе, чтобы просмотреть и устранить конфликтующий текст. Git добавил набор маркеров для указания экземпляров конфликтующего текста. Пример:
Текст между Текст между ======= и >>>>>>> является версией исходной ветви конфликтующего текста.
Измените файл, чтобы разрешить конфликтующий текст. Удаляя маркеры конфликтов слиянием, вы сообщаете Git, что вы разрешили конфликт. Например, можно изменить предыдущий текст (включая маркеры конфликтов) следующим образом:
Запустите git add , чтобы подготовить файл после разрешения всего конфликтующего текста.
Повторите предыдущие шаги для всех файлов с конфликтами содержимого.
Устранение конфликтов файлов, измененных с удалением
Конфликт измененных файлов возникает, когда один и тот же файл редактируется в одной ветви, но удаляется в другой. Для каждого удаленно измененного файла определите, какое действие ветви вы хотите использовать. Затем используйте для git add сохранения измененного файла или git rm удаления файла.
В этой статье мы рассмотрим команду git reset , которая позволит отменить неправильные/неудачные изменения, сделанные локально, а также «откатить» неудачный merge (слияние).
Обращение от редакции: Нашим защитникам из 3-го отдельного батальона УДА, которые находятся в Запорожской области, нужны вещи, чтобы противостоять врагу: квадрокоптеры и смартфоны для управления ими, прицелы ночного видения. Реквизиты для перевода средств на карту monobank – Колонович Катерина, номер карты 5375411505235312. Просим приобщиться к сбору средств. Слава Украине!
Постановка задачи
Допустим, вы работаете над проектом, и сделали изменения, которые теперь хотите отменить. Можно выполнить git status и увидеть все сделанные изменения, после чего вручную отменить ненужные. Но что если изменений очень много (такое случается после неудачных «ручных» мерджей)? В таком случае вам поможет команда git reset . Эта команда подобна скальпелю — она очень острая/эффективная, и именно поэтому ее следует использовать с осторожностью.
Далее рассмотрим основные сценарии ее использования.
Основные сведения
Вообще говоря, назначение git reset — взять текущую ветку и «сбросить» (переназначить, англ. reset ) ее так, чтобы она указывала на какой-либо другой коммит; в частности, засинхронизировать индекс и рабочее дерево репозитория. Более конкретно, если ваша ветка master (в настоящее время в статусе checkout ) выглядит так:
- A - B - C (HEAD, master)
где A, B, C — последовательные коммиты ветки master . И вы хотите, чтобы master заканчивалась коммитом B, а не С, то вы используете git reset (в данном случае — это хэш коммита B), чтобы переместить ее туда:
Важный момент: это поведение существенно отличается от команды git checkout , которая привела бы к такому результату:
- A - B (HEAD) - C (master)
В результате вы получите состояние с отсоединенным (detached) указателем HEAD . Итак, HEAD , ваше рабочее дерево, индекс — все соответствуют коммиту B, но ветка master была оставлена на коммите C. Если в данном состоянии репозитория вы сделаете новый коммит D, вы получите такую конфигурацию, которая, скорее всего, отличается от того, чего вы хотели достичь:
Запомните главное: reset не делает коммитов, он всего лишь меняет ветку (которая указывает на коммит), чтобы она указывала на другой коммит. Другими словами, что бы ни значило само слово reset , логически оно определяет, что происходит с вашим индексом и рабочим деревом.
Примеры использования
Рассмотрим некоторые основные варианты использования git reset .
Команду можно использовать для самых разных целей; общая идея состоит в том, что все они включают сброс ветки, индекса и/или рабочего дерева с тем, чтобы они указывали/соответствовали заданному коммиту.
Будьте внимательны
- Ключ –hard действительно может привести к потере результатов работы. Он модифицирует рабочее дерево репозитория.
- git reset [options] может привести (если опустить технические детали) к потере коммитов. В условном примере, приведенном выше, мы потеряли коммит C. Он по-прежнему находится в репозитории, и вы можете найти его командами git reflog show HEAD или git reflog show master, но на самом деле к нему нельзя получить доступ из какой-либо ветки.
- git окончательно и автоматически удаляет такие коммиты по истечении 30 дней, но до этого момента вы можете восстановить коммит C путем указания (checkout) ветки на этот коммит (git checkout C; git branch ).
Аргументы
Если сократить документацию git reset до одного абзаца, наиболее частый путь использования команды — git reset [] [пути. ] , что сбросит данные пути до их состояния из данного коммита. Если пути не указаны, все дерево будет сброшено («ресетнуто»), а если коммит не указан, подразумевается коммит HEAD (текущий коммит).
Это стандартный паттерн команд git (включая checkout , diff , log , хотя семантика может несколько отличаться), так что сюрпризов здесь не предвидится.
Например, git reset сбрасывает все в пути к его состоянию в ветке ; git reset — сбрасывает текущую директорию к ее состоянию в HEAD , а простой git reset сбрасывает все дерево к его состоянию в HEAD .
Основные опции для работы с деревом и индексом
Всего есть четыре опции для управления тем, что происходит с вашим рабочим деревом и индексом во время исполнения команды reset .
Напомним, «индекс» — это «сцена» git’а, условное место, где происходят изменения, когда вы, например, выполняете команду git add , подготавливая свой коммит.
- –hard — заставляет весь контент соответствовать коммиту, к которому вы сбрасываете (ресетите). Наверное, это самый простой для понимания ключ (опция). Все ваши локальные изменения исчезают. Основной случай применения — удалить вашу последнюю работу без переключения коммитов: git reset --hard означает git reset --hard HEAD , то есть, не изменяя ветку, избавиться от всех локальных изменений. Другой случай применения — перенести ветку из одного места в другое и держать при этом индекс/рабочее дерево в синхронизированном состоянии.
Напоминаем, эта опция действительно может привести к потере вашей работы, поскольку она модифицирует ваше рабочее дерево. Будьте на 100% уверены, что действительно хотите отказаться от локальных изменений, перед тем как выполнять reset --hard .
Используйте эту опцию, если осознали, что сделали несколько плохих коммитов, но сейчас состояние проекта правильное, и все что вам нужно — перекоммитить его еще раз. Индекс не тронут, поэтому вы можете закоммитить немедленно — результирующий коммит будет иметь то же содержание, которое было до выполнения reset .
- –merge — эта опция добавлена в git относительно недавно, ее предназначение — прервать неудачное (failed) слияние (merge). Это бывает необходимо, потому что git merge в принципе позволяет осуществить попытку слияния с «грязным» рабочим деревом (грязным — в смысле «с локальными изменениями»), если эти изменения содержатся в файлах, не затронутых слиянием.
git reset --merge сбрасывает индекс (подобно опции --mixed — все изменения показываются как локальные изменения) и сбрасывает все файлы, затронутые слиянием, но не трогает остальные файлы. Это может позволить восстановить все до состояния, которое было до «плохого» слияния. Скорее всего, вы будете использовать это как git reset --merge (что означает git reset --merge HEAD ), потому что хотите сбросить только изменения, вызванные попыткой слияния, а не переместить ветку (указатель HEAD не изменился, поскольку слияние было неудачным).
Если говорить более конкретно, представим, что мы поменяли файлы A и B и пытаемся «смерджиться» в ветку с измененными файлами C и D. Слияние «фейлится» по какой-либо причине, и мы решаем прервать его. Используем git reset --merge . Это приводит C и D обратно к состоянию, которое у них было в HEAD , но не затрагивает изменения в A и B, поскольку они не участвовали в попытке слияния.
Странная нотация (~ и ^)
При использовании команды git reset «странная нотация» бывает особенно полезной, поскольку позволяет указывать коммиты, близкие к HEAD , без необходимости написания их хэшей:
- HEAD~ — это сокращенная запись HEAD~1 и означает первого родителя коммита. HEAD~2 означает первого родителя у первого родителя коммита. HEAD~n можно понимать как «n коммитов перед HEAD» или «n-ый предок HEAD» .
- HEAD^ (или HEAD^1 ) тоже означает первого родителя коммита. Но вот HEAD^2 означает второго родителя коммита. Помните, коммит, представляющий собой нормальное слияние (merge), имеет двух родителей: первый родитель — это коммит, в который осуществляется слияние, а второй родитель — коммит, который был слит. Вообще говоря, слияния могут иметь произвольно много родителей (octopus merges).
- Операторы ^ и ~ могут выстраиваться в линию, например, HEAD~3^2 будет означать второго родителя предка HEAD третьего уровня; HEAD^^2 — второго родителя первого родителя HEAD ; HEAD^^^ — это просто эквивалент HEAD~3 .
Заключение
Более подробно про нашу тему в этом видео: как различить soft, mixed и hard Git Reset:
Читайте также: