Git отменяет изменения в файле

Обновлено: 21.11.2024

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

В этой короткой статье мы рассмотрим несколько способов отмены изменений в Git.

Шпаргалка Git

Не нужно запоминать все эти команды и параметры: получите нашу популярную «Шпаргалку по Git» — бесплатно!

Отмена локальных изменений в файле

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

Если вы хотите отменить изменения этого типа, вы можете использовать команду git restore:

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

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

Отмена всех локальных изменений

Если вы хотите отменить все текущие изменения, вы можете использовать команду git restore с "." параметр (вместо указания пути к файлу):

Если, кроме того, у вас есть неотслеживаемые (= новые) файлы в вашей рабочей копии и вы хотите избавиться от них, тогда вам поможет команда git clean:

Еще раз: пожалуйста, будьте осторожны с этими командами! Отменив локальные изменения, вы не сможете их вернуть!

Сохранение изменений в тайнике

Иногда вы не можете быть на 100 % уверены, что локальные изменения вам больше не нужны. Тогда вместо того, чтобы отбрасывать их, вы можете сохранить их временно:

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

Опция "извлечь" повторно применит последнее сохраненное состояние и одновременно удалит и очистит его из тайника.

Если вы используете клиент Tower Git, сохранение и восстановление из Stash можно выполнить прямо с панели инструментов:

Подробнее

Получите нашу популярную памятку по Git бесплатно!

Самые важные команды вы найдете на лицевой стороне, а полезные советы — на обратной. Более 100 000 разработчиков скачали его, чтобы сделать Git немного проще.

О нас

Как создатели Tower, лучшего клиента Git для Mac и Windows, мы помогаем более чем 100 000 пользователей в таких компаниях, как Apple, Google, Amazon, Twitter и Ebay, получить максимальную отдачу от Git.

Как и в случае с Tower, наша миссия с этой платформой – помочь людям стать лучшими профессионалами.

Вот почему мы бесплатно предоставляем наши руководства, видеоролики и памятки (об управлении версиями в Git и многих других темах).

© Tower, 2010-2022. Упомянутые названия продуктов и логотипы являются собственностью соответствующих владельцев.

Если вы изменили файл, но еще не запускали git add , вы можете отменить изменения, запустив git checkout . Вы можете указать конкретный файл, используя:

git checkout имя_файла.ipynb

Или вы можете отменить все изменения (включая все незафиксированные изменения!) с помощью:

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

Сначала измените файл README.md в репозитории. Вы можете сделать это, открыв файл в текстовом редакторе, таком как Atom, и внеся/сохранив там изменения. Или вы можете использовать bash для добавления текста в файл с помощью команды echo, как показано ниже. Убедитесь, что у вас есть cd для каталога репозитория.

После внесения изменений в файл запустите git status в терминале, чтобы убедиться, что git идентифицировал изменение.

Когда вы запустите git status , вы увидите следующий вывод:

В выводе git status также указано, что вы можете использовать git checkout -- для отмены изменений в этом файле в вашем репозитории. Итак, если вам не нравятся изменения, внесенные в файл README.md, вы можете вернуться к последней зафиксированной версии, используя:

Запустите git status, чтобы убедиться, что изменения отменены.

Содержимое вашего файла README.md было возвращено к последней сохраненной или зафиксированной версии. Таким образом, вы отбросили самые последние изменения. Вы можете открыть файл в текстовом редакторе для подтверждения!

Неустановленные изменения (после git add, до git commit)

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

Следуйте приведенным ниже шагам, чтобы попрактиковаться в отмене изменений, произошедших после git add, но до git commit .Сначала внесите новое изменение в README.md и запустите git add, чтобы подготовить измененный файл (т. е. добавить в систему управления версиями). Проверьте статус git, чтобы увидеть статус ваших изменений.

Затем запустите git add, чтобы подготовить файл (т. е. добавить в систему управления версиями) и снова запустите git status.

К счастью, вывод git status снова дает нам подсказку, как отменить поэтапные изменения. Вы можете использовать git reset имя файла HEAD, чтобы отменить изменения. HEAD относится к самой последней зафиксированной версии файла:

Подсказка: HEAD относится к самой последней версии вашего файла. Вы также можете вернуться к более старой версии, используя HEAD~1, HEAD~2 и т. д. Подробнее об этом читайте на веб-сайте уроков Software Carpentry git.

Когда вы используете git reset , ваши изменения все еще существуют в файле, но файл не был подготовлен (т. е. изменения больше не отслеживаются системой контроля версий). Итак, теперь статус git будет отображать сообщение о том, что есть изменения, которые могут быть добавлены или помещены в контроль версий. Таким образом, создается впечатление, что вы вообще никогда не запускали git add.

Теперь, когда у вас есть изменения, которые не промежуточны (т. е. не отслеживаются в системе управления версиями), вы можете снова использовать git checkout, чтобы отменить эти изменения.

Что возвращает, что в вашем репозитории нет изменений:

Git reset по существу противоположен команде git add . Это отменит git add, чтобы удалить измененный файл из системы контроля версий, а затем вы можете git checkout отменить изменения в файле.

Отменить фиксацию (после git commit, перед git push)

Если вы зафиксировали изменения в файле (т. е. запустили и git add, и git commit ) и хотите отменить эти изменения, вы можете использовать git reset HEAD~ для отмены фиксации.

Как и в предыдущем примере, когда вы используете git reset HEAD~ , изменения не будут сохранены, а затем вы можете использовать git checkout, чтобы отменить изменения в файле.

Чтобы попрактиковаться в отмене коммитов, внесите еще одно изменение в файл README.md.

Затем запустите git add, чтобы подготовить файл (т. е. добавить в систему управления версиями), а затем запустите git commit, чтобы зафиксировать файл. Проверьте статус git, чтобы увидеть статус ваших изменений.

Когда вы снова запустите git status, вы увидите, что изменения были удалены из системы управления версиями.

Обратите внимание, что теперь ваш файл не помещен в архив и, следовательно, больше не отслеживается!

На этом этапе вы можете запустить git checkout README.md, чтобы отменить изменения в файле, если хотите.

Обновлено: 30 марта 2021 г.

Поделиться

Оставить комментарий

Вам также может понравиться

График данных с помощью Matplotlib

Расчет сезонных сводных значений из переменных климатических данных, хранящихся в формате NetCDF 4: работа с климатическими данными MACA v2 в Python

Узнайте, как рассчитать сезонные сводные значения для климатических данных MACA 2, используя xarray и маску региона в Python с открытым исходным кодом.

Расчет сводных значений с использованием пространственных областей интереса (AOI), включая шейп-файлы для переменных климатических данных, хранящихся в формате NetCDF 4: работа с климатическими данными MACA v2 в Python

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

Как открыть и обработать формат данных NetCDF 4 в Python с открытым исходным кодом

Исторические и прогнозируемые климатические данные чаще всего хранятся в формате netcdf 4. Узнайте, как открывать и обрабатывать климатические данные MACA версии 2 для Continental U.

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

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

  • Узнайте, почему компания North Western Mutual выбрала GitLab для управления корпоративным исходным кодом.
  • Узнайте, как начать работу с Git.
  • Дополнительные примеры см. в книге Git.

Когда можно отменить изменения

  1. Вы создаете или редактируете файл. Он запускается в неустановленном состоянии. Если он новый, Git еще не отслеживает его.
  2. Вы добавляете файл в свой локальный репозиторий ( git add ), что переводит файл в промежуточное состояние.
  3. Вы фиксируете файл в своем локальном репозитории ( git commit ).
  4. Затем вы можете поделиться файлом с другими разработчиками, сделав коммит в удаленном репозитории ( git push ).
  • Когда вы работаете локально и еще не отправили данные в удаленный репозиторий.
  • Если вы уже отправили данные в удаленный репозиторий и хотите:
    • Сохранить историю без изменений (предпочтительно).
    • Изменить историю (требуется координация с командой и принудительные толчки).

    Отменить локальные изменения

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

    Отменить неустановленные локальные изменения

    Подтвердите, что файл не помещен в архив (что вы не использовали git add ), запустив git status :

    Чтобы перезаписать локальные изменения:

    Чтобы сохранить локальные изменения и использовать их позже:

    Чтобы навсегда отменить локальные изменения во всех файлах:

    Отменить поэтапные локальные изменения

    Подтвердите, что файл подготовлен (что вы использовали git add ), запустив git status :

    Чтобы отключить файл, но сохранить изменения:

    Чтобы отключить все, но сохранить изменения:

    Чтобы удалить файл из текущей фиксации (HEAD):

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

    Чтобы удалить все безвозвратно:

    Быстро сохранять локальные изменения

    1. В ветке, в которой вы хотите сохранить свою работу, введите git stash .
    2. Переключиться на другую ветку ( git checkout
      ).
    3. Зафиксировать, отправить и протестировать.
    4. Вернитесь в ветку, где вы хотите возобновить изменения.

    Используйте git stash list, чтобы получить список всех ранее сохраненных коммитов.

    • Используйте git stash pop, чтобы повторить ранее сохраненные изменения и удалить их из списка сохраненных.
    • Используйте git stash apply, чтобы повторить ранее сохраненные изменения, но оставить их в списке скрытых.

    Отменить зафиксированные локальные изменения

    Когда вы делаете фиксацию в своем локальном репозитории ( git commit ), Git записывает ваши изменения. Поскольку вы еще не отправили изменения в удаленный репозиторий, ваши изменения не являются общедоступными (или не доступны другим разработчикам). На этом этапе вы можете отменить свои изменения.

    Отменить поэтапные локальные изменения без изменения истории

    Вы можете отменить фиксацию, сохранив историю коммитов.

      Найдите SHA коммита, к которому вы хотите вернуться. Чтобы просмотреть журнал коммитов, введите git log.

    Чтобы поменять местами добавления и удаления изменений, внесенных фиксацией B:

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

    Чтобы отменить изменения в одном файле или каталоге из фиксации B, но сохранить их в неустановленном состоянии:

    Отменить несколько зафиксированных изменений

    Вы можете восстановиться после нескольких коммитов. Например, если вы выполнили коммиты A-B-C-D в своей функциональной ветке, а затем поняли, что C и D неверны.

    Проверьте последнюю правильную фиксацию. В этом примере Б .

    Создать новую ветку.

    Коммиты теперь A-B-C-D-E .

    Кроме того, с помощью GitLab вы можете выбрать этот коммит в новом мерж-реквесте.

    Еще одно решение — сбросить до B и зафиксировать E . Однако это решение приводит к A-B-E , что противоречит тому, что есть у других разработчиков локально.

    Отменить поэтапные локальные изменения с изменением истории

    Следующие задачи переписывают историю Git.

    Удалить определенную фиксацию

    Перебазировать диапазон от текущего коммита D до B:

    Изменить конкретную фиксацию

    Перебазировать диапазон от текущего коммита D до B:

    Откройте файл в редакторе, внесите изменения и зафиксируйте изменения:

    Восстановление отмены

    Вы можете вспомнить предыдущие локальные коммиты. Однако не все предыдущие коммиты доступны, потому что Git регулярно очищает коммиты, недоступные для веток или тегов.

    Чтобы просмотреть историю репозитория и отследить предыдущие коммиты, запустите git reflog show . Например:

    • SHA фиксации.
    • Сколько HEAD-изменяющих действий назад была сделана фиксация ( HEAD@ было 12 HEAD-изменяющих действий назад).
    • Выполненное действие, например: фиксация, перебазирование, слияние.
    • Описание действия, которое изменило HEAD .

    Отменить удаленные изменения без изменения истории

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

    Чтобы отменить изменения, внесенные в конкретную фиксацию B:

    Отменить удаленные изменения при изменении истории

    Вы можете отменить удаленные изменения и историю изменений.

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

    Когда изменение истории допустимо

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

    Когда вы вносите вклад в большие репозитории с открытым исходным кодом, такие как GitLab, вы можете сжать свои коммиты в один.

    Чтобы сжать коммиты в функциональной ветке в одну фиксацию в целевой ветке при слиянии, используйте git merge --squash .

    Как изменить историю

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

    Вы можете изменить историю, используя git rebase -i . Используйте эту команду, чтобы изменять, уничтожать и удалять коммиты.

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

    Осторожно используйте git rebase в общих и удаленных ветках. Поэкспериментируйте локально перед отправкой в ​​удаленный репозиторий.

    Удалить конфиденциальную информацию из коммитов

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

    Чтобы переписать историю с определенными фильтрами, запустите git filter-branch .

    Чтобы полностью удалить файл из истории, используйте:

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

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

    Помощь и обратная связь

    Редактируйте эту страницу, чтобы исправить ошибку или добавить улучшение в мерж-реквест.
    Создайте задачу, чтобы предложить улучшение этой страницы.
    Показывать и публиковать комментарии, чтобы просматривать и оставлять отзывы об этой странице.

    Товар

    Создайте проблему, если вам что-то не нравится в этой функции.
    Предложите функциональность, отправив запрос функции.
    Присоединяйтесь к программе First Look, чтобы помочь создавать новые функции.

    Доступность функций и пробные версии продуктов

    Просмотрите цены, чтобы увидеть все уровни и функции GitLab или обновиться.
    Попробуйте GitLab бесплатно с доступом ко всем функциям на 30 дней.

    Получить помощь

    Если вы не нашли то, что искали, выполните поиск в документации.

    Если вам нужна помощь с чем-то конкретным и вам нужна поддержка сообщества, опубликуйте сообщение на форуме GitLab.

    При возникновении проблем с настройкой или использованием этой функции (в зависимости от вашей подписки на GitLab).

    В этом разделе мы обсудим доступные стратегии и команды Git для отмены действий. Во-первых, важно отметить, что в Git нет традиционной системы «отмены», подобной той, что используется в текстовых редакторах. Было бы полезно воздержаться от сопоставления операций Git с какой-либо традиционной ментальной моделью «отмены». Кроме того, в Git есть собственная номенклатура операций «отмены», которую лучше использовать при обсуждении. Эта номенклатура включает такие термины, как сброс, возврат, проверка, очистка и т. д.

    Забавная метафора — представить Git как утилиту для управления временной шкалой. Коммиты — это моментальные снимки моментов времени или точек интереса на временной шкале истории проекта. Кроме того, несколькими временными шкалами можно управлять с помощью ветвей. При «отмене» в Git вы обычно перемещаетесь назад во времени или на другую временную шкалу, где ошибок не было.

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

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

    Идея любой системы контроля версий заключается в хранении «безопасных» копий проекта, чтобы вам никогда не приходилось беспокоиться о непоправимом нарушении базы кода. После того, как вы создали историю коммитов проекта, вы можете просмотреть и пересмотреть любую фиксацию в истории. Одной из лучших утилит для просмотра истории репозитория Git является команда git log. В приведенном ниже примере мы используем git log для получения списка последних изменений в популярной графической библиотеке с открытым исходным кодом.

    Каждая фиксация имеет уникальный идентификационный хэш SHA-1. Эти идентификаторы используются для перемещения по зафиксированной временной шкале и повторного посещения коммитов. По умолчанию git log показывает коммиты только для текущей выбранной ветки. Вполне возможно, что коммит, который вы ищете, находится в другой ветке. Вы можете просмотреть все коммиты во всех ветках, выполнив git log --branches=* . Команда git branch используется для просмотра и посещения других веток. Вызов команды git branch -a вернет список всех известных имен веток. Затем одно из этих названий веток может быть зарегистрировано с помощью git log
    .

    Когда вы нашли ссылку на фиксацию на точку в истории, которую хотите посетить, вы можете использовать команду git checkout, чтобы посетить эту фиксацию. Git checkout — это простой способ «загрузить» любой из этих сохраненных моментальных снимков на ваш компьютер для разработки. В ходе обычной разработки HEAD обычно указывает на основную или какую-либо другую локальную ветку, но когда вы извлекаете предыдущую фиксацию, HEAD больше не указывает на ветку — он указывает непосредственно на фиксацию. Это состояние называется «отключенным HEAD», и его можно визуализировать следующим образом:

    При извлечении старого файла указатель HEAD не перемещается. Он остается в той же ветке и той же фиксации, избегая состояния «отсоединенной головы». Затем вы можете зафиксировать старую версию файла в новом снимке, как и любые другие изменения. Таким образом, такое использование git checkout для файла служит способом вернуться к старой версии отдельного файла. Для получения дополнительной информации об этих двух режимах посетите страницу проверки git

    Просмотр старой версии

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

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

    Вы можете использовать git checkout, чтобы просмотреть коммит «Внесите некоторые изменения импорта в hello.txt» следующим образом:

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

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

    Отмена зафиксированного снимка

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

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

    Как отменить фиксацию с помощью git checkout

    С помощью команды git checkout мы можем проверить предыдущую фиксацию, a1e8fb5, переводя репозиторий в состояние до того, как произошла сумасшедшая фиксация. Проверка конкретного коммита переведет репозиторий в состояние "detached HEAD". Это означает, что вы больше не работаете ни в одной ветке. В отсоединенном состоянии любые новые коммиты, которые вы делаете, будут потеряны, когда вы измените ветки обратно на установленную ветку. Осиротевшие коммиты подлежат удалению сборщиком мусора Git. Сборщик мусора запускается с настроенным интервалом и безвозвратно уничтожает осиротевшие коммиты. Чтобы предотвратить сборку мусора потерянных коммитов, нам нужно убедиться, что мы находимся в ветке.

    Из состояния detached HEAD мы можем выполнить git checkout -b new_branch_without_crazy_commit . Это создаст новую ветку с именем new_branch_without_crazy_commit и переключится в это состояние. Репозиторий теперь находится на новой временной шкале истории, в которой коммит 872fa7e больше не существует. На данный момент мы можем продолжить работу над этой новой веткой, в которой коммит 872fa7e больше не существует, и считать его «отмененным». К сожалению, если вам нужна предыдущая ветвь, возможно, это была ваша основная ветвь, эта стратегия отмены не подходит. Давайте рассмотрим некоторые другие стратегии «отмены». Дополнительные сведения и примеры см. в подробном обсуждении git checkout.

    Как отменить публичную фиксацию с помощью git revert

    Предположим, мы вернулись к нашему исходному примеру с историей коммитов. История, включающая коммит 872fa7e. На этот раз давайте попробуем вернуть «отменить». Если мы выполним git revert HEAD , Git создаст новый коммит с инверсией последнего коммита. Это добавляет новую фиксацию в текущую историю веток и теперь выглядит так:

    На данный момент мы снова технически "отменили" фиксацию 872fa7e. Хотя 872fa7e все еще существует в истории, новый коммит e2f9a78 является инверсией изменений в 872fa7e. В отличие от нашей предыдущей стратегии оформления заказа, мы можем продолжать использовать ту же ветку. Это решение является удовлетворительной отменой. Это идеальный метод «отмены» для работы с общедоступными общими репозиториями. Если у вас есть требования по хранению тщательно отобранной и минимальной истории Git, эта стратегия может оказаться неудовлетворительной.

    Как отменить коммит с помощью git reset

    Для этой стратегии отмены мы продолжим наш рабочий пример. git reset — это обширная команда с множеством применений и функций. Если мы вызываем git reset --hard a1e8fb5, история коммитов сбрасывается до указанного коммита. Просмотр истории коммитов с помощью git log теперь будет выглядеть так:

    Вывод журнала показывает, что фиксации e2f9a78 и 872fa7e больше не существуют в истории фиксации. На этом этапе мы можем продолжать работать и создавать новые коммиты, как будто «сумасшедших» коммитов никогда не было. Этот метод отмены изменений имеет самое чистое влияние на историю. Выполнение сброса отлично подходит для локальных изменений, однако добавляет сложности при работе с общим удаленным репозиторием. Если у нас есть общий удаленный репозиторий, в который отправлена ​​фиксация 872fa7e, и мы попытаемся git отправить ветку, в которой мы сбросили историю, Git обнаружит это и выдаст ошибку. Git будет считать, что отправляемая ветка не актуальна из-за отсутствия коммитов. В этих сценариях git revert должен быть предпочтительным методом отмены.

    Отмена последней фиксации

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

    Отмена незафиксированных изменений

    Прежде чем изменения будут зафиксированы в истории репозитория, они сохраняются в промежуточном индексе и рабочем каталоге. Возможно, вам придется отменить изменения в этих двух областях. Промежуточный индекс и рабочий каталог — это внутренние механизмы управления состоянием Git. Для получения более подробной информации о том, как работают эти два механизма, посетите страницу git reset, где они подробно рассматриваются.

    Рабочий каталог

    Рабочий каталог обычно синхронизирован с локальной файловой системой. Чтобы отменить изменения в рабочем каталоге, вы можете редактировать файлы, как обычно, используя ваш любимый редактор. В Git есть пара утилит, помогающих управлять рабочим каталогом. Существует команда git clean, которая является удобной утилитой для отмены изменений в рабочем каталоге. Кроме того, git reset можно вызвать с параметрами --mixed или --hard, и он применит сброс к рабочему каталогу.

    Промежуточный индекс

    Команда git add используется для добавления изменений в промежуточный индекс. Сброс Git в основном используется для отмены изменений промежуточного индекса. Сброс --mixed переместит все ожидающие изменения из промежуточного индекса обратно в рабочий каталог.

    Отмена общедоступных изменений

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

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

    Обзор

    • После внесения изменений они, как правило, становятся постоянными.
    • Используйте git checkout для перемещения и просмотра истории коммитов.
    • git revert — лучший инструмент для отмены общедоступных изменений
    • git reset лучше всего использовать для отмены локальных личных изменений

    В дополнение к основным командам отмены мы рассмотрели другие утилиты Git: git log для поиска потерянных коммитов, git clean для отмены незафиксированных изменений, git add для изменения промежуточного индекса.

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

    Читайте также: