Как удалить коммит по хешу

Обновлено: 07.07.2024

Шпаргалка по консольным командам Git

Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит). Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс ( git add ), потом «сохраняем» ( git commit ).

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

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

Ключ к пониманию

Ключ к пониманию концепции git — знание о «трех деревьях»:

  • Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
  • Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
  • Директория .git/ — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).

Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.

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

Простейший цикл работ

  • Редактирование, добавление, удаление файлов (собственно, работа).
  • Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
  • Коммит (фиксация изменений).
  • Возврат к шагу 1 или отход ко сну.
  • HEAD — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
  • ORIG_HEAD — указатель на коммит, с которого вы только что переместили HEAD (командой git reset . , например).
  • Ветка ( master , develop etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
  • Теги — простые указатели на коммиты. Не перемещаются.

Перед началом работы нужно выполнить некоторые настройки:

Если вы в Windows:

Указание неотслеживаемых файлов

Файлы и директории, которые не нужно включать в репозиторий, указываются в файле .gitignore . Обычно это устанавливаемые зависимости ( node_modules/ , bower_components/ ), готовая сборка build/ или dist/ и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, возможно использование шаблонов.

Длинный вывод в консоли: Vim

Вызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой git log -p fileName.txt ). При этом прямо в консоли запускается редактор Vim. Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести :q . Переход в командный режим из любого другого: Esc .

Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w .

Боюсь, я не смог найти ничего похожего на этот конкретный сценарий.

У меня есть git-репозиторий с большой историей: 500+ веток, 500+ тегов, начиная с середины 2007 года. Он содержит

19 500 коммитов. Мы хотели бы удалить всю историю до 1 января 2010 года, чтобы сделать ее меньше и легче иметь дело (мы сохраним полную копию истории в архивном хранилище).

Я знаю, что коммит, который я хочу, стал корнем нового хранилища. Однако я не могу найти правильный git mojo для усечения репо, чтобы начать с этого коммита. Я угадываю какой-то вариант

привлечение трансплантатов будет необходимо; она также может быть необходимо для лечения каждого из 200+ ветвей , которые мы хотим сохранить отдельно , а затем патч репо вместе (то , что я действительно знаю , как это сделать).

Кто-нибудь когда-нибудь делал что-то подобное? У меня есть git 1.7.2.3, если это имеет значение.

Просто создайте прививку родителя вашего нового корневого коммита без родителя (или с пустым коммитом, например, с настоящим корневым коммитом вашего репозитория). Например echo "<NEW-ROOT-SHA1>" > .git/info/grafts

После создания трансплантата он вступает в силу сразу же; вы сможете git log увидеть и увидеть, что ненужные старые коммиты исчезли:

Если все выглядит так, как задумано, вы можете просто git filter-branch -- --all сделать его постоянным.

ВНИМАНИЕ: после выполнения шага ответвления фильтра все идентификаторы коммитов будут изменены, поэтому любой, кто использует старое репо, никогда не должен сливаться с кем-либо, использующим новое репо.

Мне пришлось сделать, git filter-branch --tag-name-filter cat -- --all чтобы обновить теги. Но у меня также есть старые теги, указывающие на старую историю, которую я хочу удалить. Как я могу избавиться от всех этих старых тегов? Если я не удаляю их, то старая история не исчезает, и я все еще могу видеть ее gitk --all . Если кому-то еще интересно, как именно это работает, это довольно просто: echo "<NEW-ROOT-HASH>" > .git/info/grafts Я согласен, объясняя, что такое взяточничество было бы более чем полезно Цитируется по ссылочной вики-странице о прививках. «Начиная с Git 1.6.5, была добавлена ​​более гибкая замена git, которая позволяет заменять любой объект любым другим объектом и отслеживает ассоциации с помощью ссылок, которые можно вставлять и перемещать между репозиториями». Так что этот ответ может быть устаревшим для текущих версий git.

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

Если вы хотите освободить место в своем репозитории git, но не хотите перестраивать все свои коммиты (перебазирование или трансплантация), и при этом можете толкать / извлекать / объединять людей, имеющих полное репо, вы можете использовать git клон мелкий клон ( параметр --depth ).

Вы можете обуздать существующее репо, выполнив следующие действия:

Ps: Старые версии git не поддерживали клонирование / push / pull из / для мелких репозиториев.

+1 Это правильный ответ для новых версий Git. (О, и, пожалуйста, возвращайтесь в PPCG !) Как вы можете cd к папке, которая была только что удалена? Я чувствую, что здесь какая-то недостающая информация. Кроме того, есть ли способ применить эти изменения к удаленному репо? @Jez Это был бы другой самый популярный ответ. Этот ответ не для вас, если вы хотите навсегда избавиться от истории. Это для работы с огромной историей. Чтобы ответить на мой собственный вопрос: git clone file:///Users/me/Projects/myProject myClonedProject --shallow-since=2016-09-02 работает как шарм! @Jez, вы можете конвертировать ваше мелкое репо в обычный, запустив git filter-branch -- --all . Это изменит все хеши в нем, но после этого вы сможете перенести его в новый репо

Этот метод прост для понимания и отлично работает. Аргументом для script ( $1 ) является ссылка (tag, hash, . ) на коммит, начиная с которого вы хотите сохранить свою историю.

Обратите внимание, что старые теги все еще будут присутствовать; поэтому вам может потребоваться удалить их вручную

примечание: я знаю, что это почти то же самое, что и @yoyodin, но здесь есть несколько важных дополнительных команд и информации. Я пытался отредактировать ответ, но, поскольку это существенное изменение в ответе @ yoyodin, мое редактирование было отклонено, поэтому вот информация!

Я ценю объяснения , данные для git prune и git gc команд. Есть ли объяснение для остальных команд в сценарии? В настоящее время неясно, какие аргументы передаются ему и что делает каждая команда. Спасибо. @ user5359531 спасибо за ваше замечание, я добавил еще несколько комментариев для каждой команды. Надеюсь это поможет. @Warpzit Я избавился от конфликтов слияний, добавив -p в rebase команду, как это было предложено в другом ответе Я точно следовал этому, и все, что я получил, было той же историей, что и раньше, с новой веткой, начинающейся с коммита, который я хотел удалить с той же историей, что и раньше. История не была удалена.

Вот $1 SHA-1 коммита, который вы хотите сохранить, и скрипт создаст новую ветвь, которая содержит все коммиты между $1 и, master и вся старая история удаляется. Обратите внимание, что этот простой сценарий предполагает, что у вас нет существующей вызванной ветви temp . Также обратите внимание, что этот скрипт не очищает данные git для старой истории. Запустите git gc --prune=all && git repack -a -f -F -d после того, как вы убедились, что вы действительно хотите потерять всю историю. Вам также может понадобиться rebase --preserve-merges предупредить, что реализация этой функции в git не идеальна. Проверьте результаты вручную, если вы используете это.

Я попробовал это, но получил конфликт слияния в rebase шаге. Странно - я не ожидал, что в этих обстоятельствах возможны конфликты слиянием. Используйте, git commit --allow-empty -m "Truncate history" если зафиксированный вами коммит не содержит файлов. Как мне вернуть это к удаленному мастеру? Когда я это делаю, я получаю и старую, и новую историю. Каким должен быть «темп»? Что вы должны передать в качестве аргумента для этого? Есть ли пример того, как эти команды должны выглядеть, когда вы на самом деле их запускаете? Спасибо. Я считаю, что 1 доллар - это хэш коммита. (Более подробная информация представлена ​​в связанной статье).

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

Да, я думаю, что вы могли бы, вероятно, сделать то, что мы хотели с этим, если бы вы взорвали также отдельную ветку полной истории. (Мы пытались уменьшить хранилище.) Я был обескуражен ответом, находящимся вне сайта; но он действительно ссылается на сайт GitScm, и учебник, на который он ссылается, написан очень хорошо и, кажется, прямо к сути вопроса ОП. @ThorSummoner К сожалению об этом! Я разработаю ответ немного более подробно на месте К сожалению, это не альтернатива переписыванию истории. В начале статьи есть запутанное предложение, которое, вероятно, произвело такое впечатление. Может ли это быть удалено из этого ответа? В статье вы увидите, что автор переписывает историю усеченной ветви, но предлагает способ присоединения устаревшей ветки «history» с помощью git replace . Я считаю, что это было исправлено в другом вопросе, где вы опубликовали этот ответ.

Если вы хотите сохранить в вверх по течению хранилище с полной историей , но местные мелкие извлечений, сделать неглубокий клон с git clone --depth=1 [repo] .

Нажав коммит, вы можете сделать

  1. git fetch --depth=1 обрезать старые коммиты. Это делает старые коммиты и их объекты недоступными.
  2. git reflog expire --expire-unreachable=now --all , Срок действия всех старых коммитов и их объектов
  3. git gc --aggressive --prune=all убрать старые предметы

Обратите внимание, что вы не можете перенести этот «мелкий» репозиторий куда-либо еще: «мелкое обновление не разрешено». См. Удалено отклонено (мелкое обновление не разрешено) после изменения удаленного URL Git . Если вы хотите этого, вы должны придерживаться прививки.

1. Игнорировать все, что старше определенного коммита

Файл .git/info/grafts может определить поддельных родителей для коммита. Строка с просто идентификатором коммита говорит, что у коммита нет родителя. Если мы хотим сказать, что мы заботимся только о последних 2000 коммитах, мы можем набрать:

git rev-parse дает нам идентификатор коммита 2000-го родителя текущего коммита. Приведенная выше команда перезапишет файл трансплантатов, если он присутствует. Проверьте, если это там в первую очередь.

2. Переписать историю Git (необязательно)

Если вы хотите, чтобы этот привитый поддельный родитель был реальным, выполните:

Это изменит все идентификаторы коммитов. Каждая копия этого хранилища должна быть принудительно обновлена.

3. Очистить место на диске

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

Альтернатива: мелкие копии

Если у вас есть мелкая копия другого хранилища и вы просто хотите сэкономить место на диске, вы можете выполнить обновление .git/shallow . Но будьте осторожны, чтобы ничто не указывало на коммит из ранее. Таким образом, вы можете запустить что-то вроде этого:

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

Если у вас все еще есть старые ссылки (теги, ветви, удаленные заголовки), которые указывают на более старые коммиты, они не будут очищены и вы не сэкономите больше дискового пространства.

Поддержка <GIT_DIR> / info / grafts устарела и будет удалена в следующей версии Git.

При перебазировании или толкании к голове / мастеру эта ошибка может возникнуть

Для решения этой проблемы в git dashboard следует удалить главную ветку из «Защищенных веток»

введите описание изображения здесь

тогда вы можете запустить эту команду

Выше команда печати SHA, например, d10f7503bc1ec9d367da15b540887730db862023 .

Теперь просто введите:

Сначала все файлы будут помещены 8365366 в фиктивный коммит d10f750 . Затем он будет воспроизводить все коммиты после 8365366 поверх d10f750 . Наконец, master указатель ветви будет обновлен до последнего воспроизведенного коммита.

Теперь, если вы хотите подтолкнуть эти усеченные репо, просто сделайте git push -f .

Несколько вещей, которые нужно иметь в виду (это относится и к другим методам, а также к этому): теги не передаются. Хотя идентификаторы и временные метки сохранены, вы увидите, что GitHub показывает эти коммиты в виде единовременного заголовка Commits on XY date .

К счастью, усеченную историю можно сохранить как «архив», и позже вы можете присоединиться к урезанному репо с архивным репо. Для этого смотрите это руководство .

Я знаю, что это переписывание истории, что плохо, яда, яда.

Но как навсегда удалить несколько коммитов из удаленной ветки?

Да, это действительно плохо, яда, яда, но по какой-то причине мне это нужно. Я знаю, что это глупо, но иногда случается дерьмо - например, тестирование логинов и использование простых текстовых паролей в коде, которые являются настоящими учетными данными для входа. И возгласы . реальные учетные данные для входа в систему .. Да, напоминает мне о некоторых возгласах Я так устал от этой академической болтовни о том, насколько это опасно и как это никогда не должно быть сделано Яда Яда. Временами гораздо лучше удалять вещи из истории git и справляться с конфликтами / взломом других разработчиков. Это действительно так просто. Люди, которые игнорируют это, вероятно, никогда не работали вне классной комнаты.

Вы git reset --hard Ваше местное отделение , чтобы удалить изменения из рабочего дерева и индекса, и вы git push --force исправленное местное отделение на пульт дистанционного управления. ( другое решение здесь , включающее удаление удаленной ветви и повторное ее нажатие)

Этот SO-ответ иллюстрирует опасность такой команды, особенно если люди зависят от удаленной истории для своих локальных репозиториев.
Вы должны быть готовы указывать на людей в разделе « ВОССТАНОВЛЕНИЕ ОТ UPSTREAM REBASE » на git rebase странице руководства.

В Git 2.23 (август 2019 года, девять лет спустя) вы будете использовать новую команду git switch .
То есть: (заменить git switch -C mybranch origin/mybranch

n
n на количество коммитов для удаления)

Это восстановит индекс и рабочее дерево, как если git reset --hard бы.

Странный. Кажется, я уже пробовал это. Вместе с некоторым перебазированием - работает как шарм. Спасибо. Я использовал BFG Repo-Cleaner, чтобы избавиться от некоторых конфиденциальных данных, в результате чего у меня осталась «неназванная» ветвь с исходным файлом, после сброса до последнего требуемого коммита и жесткого нажатия на источник все прошло нормально (: Обратите внимание, что URL коммита еще жив (по крайней мере, в течение некоторого времени), поэтому, если у кого-то есть URL коммита (вы дали его богу знает почему), он сможет получить доступ к коду.

Просто обратите внимание, чтобы использовать last_working_commit_id , при отмене нерабочего коммита

Поэтому мы не должны возвращаться к commit_id чего мы не хотим.

Тогда обязательно, мы должны нажать на удаленную ветку:

Идеальный, элегантный, самый простой ответ. Я только что вернулся к последнему фиксированному Это заставило меня потерять свои локальные изменения тоже. Я не ожидал этого. Но лучше, чем вводить свой личный пароль для работы репо. Вы можете сохранить свои локальные изменения с помощью git stash . сделать некоторые вещи . и git stash pop (ваши локальные изменения вернулись) Это дает мне ошибку как «remote: error: запрещение не-ускоренных

Важно: Убедитесь, что вы указали, какие ветки в git push -f, или вы можете случайно изменить другие ветки! [*]

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

  1. Отменить полный коммит
  2. Удалить последний коммит
  3. Удалить коммит из списка

1 Отменить полный коммит

2 Удалить последний коммит

или, если филиал доступен локально

где + dd61 . ваш хеш коммита, а git интерпретирует x ^ как родительский элемент x, а + как принудительный небыстрый push.

3 Удалить коммит из списка

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

Убедитесь, что вы указали, какие ветви в «git push <remote_repo> <remote_branch> -f», или вы можете случайно изменить другие ветви! Только шаги 1 и 2 сделали работу и ответили на оригинальный вопрос. (Не выполняйте шаг 3) Это варианты для разных сценариев, а не шаги, которые нужно предпринять. В моем случае интерактивная перебазировка (вариант 3) сделала то, что я искал. Я должен был сделать шаг 3, хотя. Почему бы тебе не запустить этот @Saad? К счастью, мой «remote» был просто «origin» по умолчанию, а <remote_branch> «master» по умолчанию

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

Затем выполните следующую команду (на локальном компьютере), чтобы заставить удаленную ветвь переписать свою историю:

Поздравляем! Все сделано!

Некоторые заметки:

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

После этого вы можете заменить HEAD

N с <desired-commit-id> следующим образом:

Если вы хотите сохранить изменения в файловой системе и просто изменить индекс (историю фиксации), используйте --soft флаг вроде git reset --soft HEAD

3 . Тогда у вас есть шанс проверить свои последние изменения и сохранить или удалить все или их часть. В последнем случае runnig git status показывает файлы, измененные с тех пор <desired-commit-id> . Если вы используете --hard опцию, git status вам сообщат, что ваша локальная ветка точно такая же, как и удаленная. Если вы не используете --hard ни --soft , используется режим по умолчанию --mixed . В этом режиме git help reset говорит:

Сбрасывает индекс, но не рабочее дерево (т. Е. Измененные файлы сохраняются, но не помечаются для фиксации) и сообщает, что не было обновлено.

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

Как отменить коммит в Git

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


Команда вернет список коммитов с их описанием и идентификаторами (хешами), которые можно использовать для того чтобы посмотреть подробную информацию о коммите с помощью команды show. По умолчанию команда показывает изменения в последнем коммите:


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

1. Отменить коммит, но оставить изменения

Для того чтобы отменить последний коммит git без удаления изменений используется команда reset с параметром --soft. Команде надо передать идентификатор коммита или его позицию относительно HEAD. В терминологии git термин HEAD - это самая последняя версия проекта в текущей ветке. С помощью HEAD можно ссылаться на коммиты в истории. Для этого используется символ

. Таким образом ссылка на предыдущий коммит будет выглядеть как HEAD

или HEAD

1, а на коммит перед ним - HEAD

2 и так далее. Для отмены последнего коммита достаточно выполнить команду:

git reset --soft HEAD


Как видите, все файлы сохранились, а если посмотреть отличия HEAD и текущего состояния проекта, то будет видно, добавление файла file3:


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

А затем передайте его в команду git reset. Например:

git reset --soft 887080eea5fd8bd3bc2503dcf043ac6f5c19a8e5


И снова все файлы на месте, а в HEAD теперь будет добавлено два файла: file2 и file3:


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

Обратите внимание, что файлы, которые ранее были в коммите, сейчас всё ещё добавлены в индекс, поэтому вам не надо вызывать git add, можно сразу создавать новый коммит. Но у команды reset есть ещё одна опция: --mixed. Она используется по умолчанию. При использовании этой опции ваши изменения тоже сохраняются, но перед следующим коммитом их снова надо будет добавить в индекс с помощью git add. При выполнении команды git status эти файлы будут отображаться как не отслеживаемые:


2. Отменить коммит и удалить изменения

Отмена коммита git с удалением изменений работает аналогично. Только здесь необходимо вместо опции --soft указывать опцию --hard. Например, при той же структуре коммитов, можно удалить последний коммит с добавлением файла file3 вместе с этим файлом:

git reset --hard HEAD


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

3. Как вернуть отмененный коммит

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

Затем, для того чтобы вернуться к нужному удалённому коммиту надо использовать ту же команду reset --hard со ссылкой на удалённый коммит, полученной из предыдущей команды, в виде HEAD . Например, для коммита c файлом file3 это будет выглядеть так:

git reset --hard HEAD@


Аналогично можно использовать адрес:

git reset --hard fc1f295

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

git fsck --lost-found


Затем просто используйте идентификатор коммита для того чтобы посмотреть какие в нём были изменения:

git show 8a996dd76fbacb05a2df91c0f2d19b1a3afd8451


Затем можно переключиться на этот коммит с помощью команды:

git rebase 8a996dd76fbacb05a2df91c0f2d19b1a3afd8451


Это всё тоже безопасно делать только с коммитами, ещё не отправленными в удалённый репозиторий.

4. Отменить изменения но не отменять коммит

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


Затем выполните команду revert, например:

git revert 8a996dd76fbacb05a2df91c0f2d19b1a3afd8451



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

Выводы

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

Нет похожих записей


Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

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