Как отменить последний коммит git
Как отменить последний коммит git
Как отменить последний коммит git
Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).
See «Reset, restore and revert» in git[1] for the differences between the three commands.
OPTIONS
With this option, git revert will let you edit the commit message prior to committing the revert. This is the default if you run the command from a terminal.
Usually you cannot revert a merge because you do not know which side of the merge should be considered the mainline. This option specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent.
Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want.
With this option, git revert will not start the commit message editor.
Usually the command automatically creates some commits with commit log messages stating which commits were reverted. This flag applies the changes necessary to revert the named commits to your working tree and the index, but does not make the commits. In addition, when this option is used, your index does not have to match the HEAD commit. The revert is done against the beginning state of your index.
This is useful when reverting more than one commits’ effect to your index in a row.
Add a Signed-off-by trailer at the end of the commit message. See the signoff option in git-commit[1] for more information.
Use the given merge strategy. Should only be used once. See the MERGE STRATEGIES section in git-merge[1] for details.
Pass the merge strategy-specific option through to the merge strategy. See git-merge[1] for details.
Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible.
SEQUENCER SUBCOMMANDS
Skip the current commit and continue with the rest of the sequence.
Forget about the current operation in progress. Can be used to clear the sequencer state after a failed cherry-pick or revert.
Cancel the operation and return to the pre-sequence state.
EXAMPLES
Revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes.
Revert the changes done by commits from the fifth last commit in master (included) to the third last commit in master (included), but do not create any commit with the reverted changes. The revert only modifies the working tree and the index.
Как отменить последний коммит
Допустим, вы работаете над кодом в Git и вдруг что-то пошло не по плану. Вам нужно отменить ваш последний коммит. Как это сделать? Давайте разберемся!
Отменить последний коммит можно двумя способами. В этой статье мы рассмотрим оба.
Команда git revert
Команда git revert создает коммит, который возвращает изменения, внесенные с указанным коммитом. С помощью этой команды можно отменить последний коммит:
Найти имя коммита, который нужно вернуть, можно при помощи команды git log. Первый коммит в выдаче и будет вашим последним созданным коммитом.
Вы можете скопировать его хэш (цифробуквенный идентификатор) и использовать его в команде revert.
Команда git reset
Отменить последний коммит можно также при помощи команды git reset. Но будьте осторожны: это изменит историю коммитов. Пользуйтесь этой командой пореже.
Эта команда смещает HEAD на последний коммит. По умолчанию используется опция —mixed. Все изменения после указанного коммита останутся в рабочем каталоге как неотслеживаемые.
Опция —soft позволяет сохранить незакоммиченные изменения (если они были) как staged.
Если вы хотите сбросить все до последнего коммита, а также удалить все неподготовленные изменения, можно использовать опцию —hard.
Таким образом вы вернетесь в положение до последнего коммита, но вместе с тем сотрете все изменения, не попавшие в коммит.
Что лучше использовать: reset или revert?
Используйте reset исключительно для сброса коммитов, существующих лишь локально. Эта команда меняет историю коммитов. А это может негативно сказаться на работе удаленных членов команды, которые могли основывать что-то на коммите, который вы сотрете.
Команда revert создает новый коммит, отменяющий изменения, и не перезаписывает историю коммитов. Так что, если коммит, который вы хотите вернуть, уже был запушен в общий репозиторий, лучше использовать revert.
Заключение
Мы разобрали два способа отменить последний коммит, а также разобрали, когда какой лучше использовать.
Теперь вы знаете, что делать, если вы вдруг заметите баг в вашем последнем коммите, или окажется, что изменения вовсе не должны были попасть в коммит!
Как отменить commit и не облажаться
Возьмем простую ситуацию: разработчик решает реализовать математические функции. Но на половине пути понимает, что данную задачу было бы хорошо декомпозировать, допустим, на две подзадачи:
Проверять будет проще да и тестировать. Но он уже начал ее реализовывать, коммиты уже созданы, и что же делать? Не переписывать же!
git revert
Работа кипит и осталось дело за малым — смерджить мастер с данными ветками.
И что же мы получили? Ни класса Arithmetic, ни класса Numerical!
А все дело в том, что команда git revert создает новый коммит с отменой изменений и не удаляет из истории коммиты. И в нашем случае после слияния веток получается 4 коммита:
То есть вариант с отменой изменений с помощью команды revert вышел нам боком.
git reset
git rebase
Есть еще одно решение — использовать команду git rebase для отмены изменений.
Вернемся к моменту создания двух веток numerical и arithmetic и выполним
Теперь на уровне каждого коммита, который мы хотим отменить заменим pick на drop. И тогда выбранные нами коммиты сбросятся из истории. Например в ветке numerical :
Тогда в истории у нас останутся только нужные нам коммиты.
Теперь при слиянии веток в master получим оба класса.
Данный метод рабочий, только при условии работы в частной ветке, но если эти манипуляции провести в общей ветке, то при публикации ( git push ) git сообщает, что ветка устарела, так как в ней отсутствуют коммиты и отменяет публикацию.
Чтобы не бороться с git, старайтесь декомпозировать задачи заранее, а то можете словить сюрприз. Сталкивались ли вы с такими ситуациям, и если да, то как выходили из них?
Как отменить последний Git-коммит
Из статьи вы узнаете, как правильно отменить последний Git-коммит. Приведена не только теория, но также необходимые команды.
Работая с системой управления версиями Git, вы рано или поздно столкнетесь с распространенной проблемой: случайный коммит ненужных критических изменений. Неплохо, если это только ваш проект, но если речь идет о чем-то более масштабном, предназначенном для целой команды разработчиков, такие ситуации оказываются очень неприятными. Разберемся, как это исправить.
Удалите Git-коммит новым коммитом
Звучит как нонсенс, но только на первый взгляд. Суть в том, что выполняется пустой коммит, который удаляет нежелательные изменения после предыдущего.
Команда revert означает возврат состояния к HEAD – последнему коммиту в ветке.
Появится следующее сообщение:
Чтобы удостовериться, что все сделано правильно, выполняется:
Предыдущий неправильный коммит будет присутствовать в логах, но также вы увидите его удаление:
Проверьте Git-статус следующей командой:
Используйте команду reset
Как видите, revert оставляет «следы» в истории ветки, а иногда нужно подобную ошибку скрыть. К возможностям reset относятся:
Для начала отметьте нужную ветку:
Теперь выполните сброс до коммита oops:
Однако все равно ничто не теряется. Запустите команду отображения всех коммитов:
Вас также могут заинтересовать другие статьи по теме:
git revert
Можно сказать, что команда git revert представляет собой типичную команду отмены. Однако принцип ее действия отличается от привычной отмены изменений. Вместо удаления коммита из истории проекта эта команда отменяет внесенные в нем изменения и добавляет новый коммит с полученным содержимым. В результате история в Git не теряется, что важно для обеспечения целостной истории версий и надежной совместной работы.
Отмена с помощью команды revert необходима, когда нужно обратить изменения, внесенные в некоем коммите из истории проекта. Это может быть полезно, если баг появился в проекте из-за конкретного коммита. Вам не потребуется вручную переходить к этому коммиту, исправлять его и выполнять коммит нового снимка состояния — команда git revert сделает это автоматически.
.svg "03%20(7)")
Порядок действий
Для наглядности создадим тестовый репозиторий и напишем в командной строке следующее:
Обратите внимание, что после операции отмены третий коммит по-прежнему содержится в истории проекта. Вместо его удаления команда git revert добавила новый коммит для отмены изменений. В результате второй и четвертый коммиты представляют собой одну и ту же базу кода, а третий коммит хранится в истории на случай, если в дальнейшем нам понадобится к нему вернуться.
Распространенные опции
Это параметр по умолчанию, указывать его необязательно. Он открывает настроенный системный редактор, в котором вам будет предложено изменить комментарий к коммиту перед выполнением отмены
Разница между командами git reset и git revert
Важно понимать, что команда git revert отменяет одиночный коммит, но не возвращает проект в предшествовавшее состояние с удалением всех последующих коммитов. Такой результат в Git дает команда reset, а не revert.
.svg "04%20(2)")
У команды revert есть два серьезных преимущества перед командой reset. Во-первых, она не изменяет историю проекта и, соответственно, безопасна для коммитов, которые уже опубликованы в общем репозитории. Подробнее о том, почему изменять общую историю опасно, см. на странице команды git reset.
Резюме
Готовы изучить команду git revert?
Ознакомьтесь с этим интерактивным обучающим руководством.
16. Отмена коммитов
01 Отмена коммитов
Иногда вы понимаете, что новые коммиты являются неверными, и хотите их отменить. Есть несколько способов решения этого вопроса, здесь мы будем использовать самый безопасный.
Мы отменим коммит путем создания нового коммита, отменяющего нежелательные изменения.
02 Измените файл и сделайте коммит
Измените файл hello.html на следующий.
Файл: hello.html
Выполните:
03 Сделайте коммит с новыми изменениями, отменяющими предыдущие
Чтобы отменить коммит, нам необходимо сделать коммит, который удаляет изменения, сохраненные нежелательным коммитом.
Выполните:
Перейдите в редактор, где вы можете отредактировать коммит-сообщение по умолчанию или оставить все как есть. Сохраните и закройте файл. Вы увидите…
Результат:
Так как мы отменили самый последний произведенный коммит, мы смогли использовать HEAD в качестве аргумента для отмены. Мы можем отменить любой произвольной коммит в истории, указав его хэш-значение.
04 Проверьте лог
Проверка лога показывает нежелательные и отмененные коммиты в наш репозиторий.
Выполните:
Результат:
Эта техника будет работать с любым коммитом (хотя, возможно, возникнут конфликты). Она безопасна в использовании даже в публичных ветках удаленных репозиториев.
05 Далее
Далее давайте посмотрим на технику, которая может быть использована для удаления последних коммитов из истории репозитория.
Полезные команды Git: безопасная отмена коммитов, добавление файла из другой ветки и другие
Git — это мощный, хотя и незамысловато выглядящий, инструмент, который при неосторожном использовании может устроить большой беспорядок. Поэтому, прежде чем пробовать выполнять различные фокусы с Git, я рекомендую ознакомиться с его основными командами (init, clone, push, pull, status, log и т.д.) и концептами (репозиторий, ветвь, коммит, и т.д.).
Итак, если вы уверенно чувствуете себя при работе с Git, вот несколько полезных трюков, о которых я знаю.
Reflog. Отмена операций
Я помню, что в начале знакомства с Git я боялся запускать команды. Я думал, что всё испорчу. Например, первое использование git rebase вызвало у меня несколько восклицаний наподобие «Вот *****! Что я только что сделал?!» из-за дублировавшихся или вообще исчезнувших коммитов. Вскоре после этого я понял, что нужно идти дальше.
Лично я не люблю использовать инструмент, не зная, что именно он делает для достижения результата. Это как вождение машины без руля: всё прекрасно до тех пор, пока не доедешь до поворота. А что потом? Ну, вы меня поняли.
или относительную ссылку:
и вы окажетесь в независимом (detached) состоянии HEAD, из которого можно создать новую ветвь.
Вот и всё. Все операции после вышеуказанного состояния отменены.
Revert. Отмена изменений коммита
Вы, должно быть, сталкивались с ситуацией, когда вам нужно было отменить некоторые изменения. На помощь придёт команда revert :
Что она делает? Она просто отменяет действия прошлых коммитов, создавая новый, содержащий все отменённые изменения. Зачем использовать её вместо других решений? Это — единственный безопасный способ, так как он не изменяет историю коммитов. Он обычно используется в публичных ветвях, где изменение истории нежелательно.
Давайте взглянем на другие команды, способные отменять действия.
Rebase
Вы можете выполнить эту команду и просто убрать строки, относящиеся к ненужным коммитам. Это самое очевидное и простое решение, но у него есть недостаток, из-за которого его нельзя использовать в публичных ветвях: он изменяет историю коммитов. Поэтому после rebase’а у вас может возникнуть проблема с push’ем.
Reset
Эта команда удаляет все коммиты выше указанного. Она лучше предыдущей тем, что не добавляет новую информацию в историю, но тем не менее тоже ее меняет.
Checkout
Эта команда откатывает выбранный файл к состоянию в более ранней версии указанного коммита. Отменённые изменения будут в рабочей директории, и их можно будет закоммитить как угодно.
Вывод таков, что git revert — самая безопасная операция для отмены действий. Кроме того, нужно заметить, что эти команды не взаимозаменяемы в 100% случаев.
Log. Более приятное форматирование
С git log всё просто. Вы вводите команду и видите историю коммитов в хронологическом порядке, и каждый пункт включает в себя хэш коммита, автора, дату и прикреплённое сообщение.
Давайте взглянем на вид лога по умолчанию:
Я думаю, что могло бы быть и лучше.
Я предпочитаю простые вещи. Поэтому я использую две опции:
Вот как это выглядит:
Тем не менее, иногда нам нужно знать дату и автора коммита. В таких случаях я использую следующее:
Ничего себе! Давайте посмотрим, как это выглядит:
И всё-таки вводить эти команды каждый раз достаточно неудобно, так? Давайте создадим алиасы. Я считаю, что использование алиасов очень сильно повышает продуктивность. Чтобы зарегистрировать их, добавим следующие строки в «
/.bash_profile» (конечно, если вы используете *nix OS):
Еще один вариант украшения вывода лога приведен в этой статье.
Diff. Разница между коммитами
Другой — вывод всех изменений, не внесённых в индекс. Для этого нужно выполнить следующее:
Branch. Проверка ветвей на слияние
Я думаю, вы уже знаете, что делает базовая команда git branch (без опций выводит список локальных веток — прим. перев.), поэтому перейдём к делу. Время от времени вам понадобится удалять старые или ненужные ветви из вашего «дерева» git.
вы получите список всех веток, соединённых с текущей.
Можно и наоборот:
Так вы получите список всех не соединённых с текущей веток.
Таким образом, вы всегда узнаете, безопасно ли удаление той или иной ветви.
Checkout. Получение файла из другой ветви
Указанный файл будет приведен к версии, указанной в заданном коммите. Раньше мы использовали это для отмены изменений файла. Удобно то, что этот коммит необязательно должен находиться в той же ветви, что и наш файл. Поэтому мы можем задать любому файлу любую версию из любого коммита или ветви.
Надеюсь, вы нашли здесь для себя что-то полезное. Прошу заметить, что все вышеуказанные моменты субъективны, поскольку я подгонял их под свои нужды.
Git для начинающих. Часть 9. Как удалить коммит в git?
Рассмотрим довольно важный вопрос: как удалить коммит в git? Начнем с вопроса отмены изменений в рабочей директории, после этого перейдем к репозиторию. В рамках этой темы изучим вопросы удаления и замены последнего коммита, работу с отдельными файлами и использование команд git revert и git reset.
Отмена изменений в файлах в рабочей директории
Если вы сделали какие-то изменения в файле и хотите вернуть предыдущий вариант, то для этого следует обратиться к репозиторию и взять из него файл, с которым вы работаете. Таким образом, в вашу рабочую директорию будет скопирован файл из репозитория с заменой. Например, вы работаете с файлом main.c и внесли в него какие-то изменения. Для того чтобы вернуться к предыдущей версии (последней отправленной в репозиторий) воспользуйтесь командой git checkout.
Отмена коммитов в git
Работа с последним коммитом
Для демонстранции возможностей git создадим новый каталог и инициализируем в нем репозиторий.
Добавим в каталог файл main.c.
Отправим изменения в репозиторий.
Внесем изменения в файл.
И сделаем еще один коммит.
В репозиторий, на данный момент, было сделано два коммита.
Теперь удалим последний коммит и вместо него отправим другой. Предварительно изменим содержимое файла main.c.
Отправим изменения в репозиторий с заметой последнего коммита.
Как вы можете видеть: из репозитория пропал коммит с id=d142679, вместо него теперь коммит с id=18411fd.
Отмена изменений в файле в выбранном коммите
Сделаем ещё несколько изменений в нашем файле main.c, каждое из которых будет фиксироваться коммитом в репозиторий.
Помните, что в предыдущем разделе мы поменяли коммит с сообщением “second commit” на “third commit”, поэтому он идет сразу после “first commit”.
Представим ситуацию, что два последних коммита были неправильными, и нам нужно вернуться к версии 18411fd и внести изменения именно в нее. В нашем примере, мы работаем только с одним файлом, но в реальном проекте файлов будет много, и после коммитов, в рамках которых вы внесли изменения в интересующий вас файл, может быть ещё довольно много коммитов, фиксирующих изменения в других файлах. Просто так взять и удалить коммиты из середины ветки не получится – это нарушит связность, что идет в разрез с идеологией git. Одни из возможных вариантов – это получить версию файла из нужного нам коммита, внести в него изменения и сделать новый коммит. Для начала посмотрим на содержимое файла main.c из последнего, на текущий момент, коммита.
Для просмотра содержимого файла в коммите с id=18411fd воспользуемся правилами работы с tree-ish (об этом подробно написано здесь)
Переместим в рабочую директорию файл main.c из репозитория с коммитом id=18411fd.
Мы видим, что теперь содержимое файла main.c соответствует тому, что было на момент создания коммита с id=18411fd. Сделаем коммит в репозиторий и в сообщении укажем, что он отменяет два предыдущих.
Таким образом мы вернулись к предыдущей версии файла main.c и при этом сохранили всю историю изменений.
Использование git revert для быстрой отмены изменений
Рассмотрим ещё одни способ отмены коммитов, на этот раз воспользуемся командой git revert.
В нашем примере, отменим коммит с id=cffc5ad. После того как вы введете команду git revert (см. ниже), система git выдаст сообщение в текстовом редакторе, если вы согласны с тем, что будет написано в открытом файле, то просто сохраните его и закройте. В результате изменения будут применены, и автоматически сформируется и отправится в репозиторий коммит.
Если вы хотите поменять редактор, то воспользуйтесь командой.
Обратите внимание, что в этом случае будут изменены настройки для текущего репозитория. Более подробно об изменении настроек смотрите в “Git для начинающих. Часть 3. Настройка Git”
Проверим, применялась ли настройка.
Посмотрим на список коммитов в репозитории.
Содержимое файла вернулось к тому, что было сделано в рамках коммита с >
Отмена группы коммитов
ВНИМАНИЕ! Используйте эту команду очень аккуратно!
Если вы не знакомы с концепцией указателя HEAD, то обязательно прочитайте статью “ Git для начинающих. Часть 7. Поговорим о HEAD и tree-ish“. HEAD указывает на коммит в репозитории, с которого будет вестись дальнейшая запись, т.е. на родителя следующего коммита. Существует три опции, которые можно использовать с командой git reset для изменения положения HEAD и управления состоянием stage и рабочей директории, сейчас мы все это подробно разберем.
Удаление коммитов из репозитория (без изменения рабочей директории) (ключ –soft)
Для изменения положения указателя HEAD в репозитории, без оказания влияния рабочую директорию (в stage, при этом, будет зафиксированно отличие рабочей директории от репозитория), используйте ключ –soft. Посмотрим ещё раз на наш репозиторий.
Содержимое файла main.с в рабочей директории.
Содержимое файла main.с в репозитории.
Теперь переместим HEAD в репозитории на коммит с id=dcf7253.
Получим следующий список коммитов.
Содержимое файла main.c в репозитории выглядит так.
В рабочей директории файл main.c остался прежним (эти изменения отправлены в stage).
Для того, чтобы зафиксировать в репозитории последнее состояние файла main.c сделаем коммит.
Посмотрим на список коммитов.
Как видите из репозитория пропали следующие коммиты:
Удаление коммитов из репозитория и очистка stage (без изменения рабочей директории) (ключ –mixed)
Если использовать команду git reset с аргументом –mixed, то в репозитории указатель HEAD переместится на нужный коммит, а также будет сброшено содержимое stage. Отменим последний коммит.
В результате изменилось содержимое репозитория.
Содержимое файла main.c в последнем коммите выглядит так.
Файл main.c в рабочей директории не изменился.
Отправим изменения вначале в stage, а потом в репозиторий.
Удаление коммитов из репозитория, очистка stage и внесение изменений в рабочую директорию (ключ –hard)
Если вы воспользуетесь ключем –hard, то обратного пути уже не будет. Вы не сможете восстановить данные из рабочей директории. Все компоненты git (репозиторий, stage и рабочая директория) будут приведены к одному виду в соответствии с коммитом, на который будет перенесен указатель HEAD.
Текущее содержимое репозитория выглядит так.
Посмотрим на содержимое файла main.c в каталоге и репозитории.
Содержимое файлов идентично.
Удалим все коммиты до самого первого с id=86f1495.
Состояние рабочей директории и stage.
Содержимое файла main.c в репозитории и в рабочей директории.
Т.к. мы воспользовались командой git reset с ключем –hard, то восстановить прежнее состояние нам не получится.
БУДЬТЕ ОЧЕНЬ АККУРАТНЫ С ЭТОЙ КОМАНДОЙ!
Git для начинающих. Часть 9. Как удалить коммит в git? : 2 комментария
Это отменяет последний коммит, но не возвращает файл в исходное состояние.
А в какой задаче это может быть полезно?
Эта команда перезаписывает последний коммит (т.е. последний удаляется и на его место встает новый), файл в исходное состояние не возвращается.
А в какой задаче это может быть полезно?
хм… хороший вопрос! Даже затрудняюсь на него ответить. Ну например, вы закоммитили какой-то “ужас” и не хотите, чтобы он стал достоянием общественности))
17. Удаление коммитов из ветки
Revert из предыдущего раздела является мощной командой, которая позволяет отменить любые коммиты в репозиторий. Однако, и оригинальный и «отмененный» коммиты видны в истории ветки (при использовании команды git log ).
01 Команда reset
Мы уже видели команду reset и использовали ее для согласования буферной зоны и выбранного коммита (мы использовали коммит HEAD в нашем предыдущем уроке).
При получении ссылки на коммит (т.е. хэш, ветка или имя тега), команда reset …
02 Проверьте нашу историю
Давайте сделаем быструю проверку нашей истории коммитов.
Выполните:
Результат:
03 Для начала отметьте эту ветку
Но прежде чем удалить коммиты, давайте отметим последний коммит тегом, чтобы потом можно было его найти.
Выполните:
04 Сброс коммитов к предшествующим коммиту Oops
Глядя на историю лога (см. выше), мы видим, что коммит с тегом «v1» является коммитом, предшествующим ошибочному коммиту. Давайте сбросим ветку до этой точки. Поскольку ветка имеет тег, мы можем использовать имя тега в команде сброса (если она не имеет тега, мы можем использовать хэш-значение).
Выполните:
Результат:
05 Ничего никогда не теряется
Что же случается с ошибочными коммитами? Оказывается, что коммиты все еще находятся в репозитории. На самом деле, мы все еще можем на них ссылаться. Помните, в начале этого урока мы создали для отмененного коммита тег «oops». Давайте посмотрим на все коммиты.
Выполните:
Результат:
06 Опасность сброса
Сброс в локальных ветках, как правило, безопасен. Последствия любой «аварии» как правило, можно восстановить простым сбросом с помощью нужного коммита.
Однако, если ветка «расшарена» на удаленных репозиториях, сброс может сбить с толку других пользователей ветки.
Самые типичные ошибки и вопросы, связанные с Git, и удобные способы их решения
Если вы хотите получше узнать те части Git, про которые раньше боялись спросить, то этот список для вас. Тут собраны наиболее типичные ситуации и способы их решения как из личного опыта автора, так и собранные по всему Интернету.
Ошибка в комментарии к коммиту
Если коммит ещё не был отправлен на сервер (push), то можно воспользоваться простой командой, позволяющей редактировать текст сообщения к последнему коммиту:
Как отменить последний коммит?
1 означает один коммит до HEAD, т.е. до текущего положения. Стоит заметить, что это «ядерный» способ, который отменит все изменения. Если вам нужно сохранить всё, что вы сделали, но еще не успели закоммитить, используйте:
Удалить ветку на сервере
В чём разница между «git pull» и «git fetch»?
Как отменить «git add» до коммита?
Вы выполнили git add имя_файла случайно и хотите отменить добавление файла. Если коммит ещё не был сделан, то поможет:
git reset имя_файла
Как разрешать конфликты слияния?
Удалить все локальные файлы и директории, которые не отслеживает Git, из вашей текущей копии
Осторожно! Лучше сделайте перед этим бэкап.
Клонировать все ветки с сервера
Скорее всего, вы это уже сделали, а ветки просто скрыты. Вот команда, чтобы показать их:
Переименовать локальную ветку
Вернуться к любому коммиту
Ещё раз повторим: команда отменит все текущие изменения, так что убедитесь, что вам это действительно нужно. Или используйте --soft вместо --hard.
Удалить подмодуль (submodule)
Создание подмодулей используется довольно редко, но иногда они всё-таки встречаются. Вот, что вам нужно:
Перезаписать локальные файлы во время git pull
Вам снова поможет git reset :
Как добавить пустую директорию в репозиторий?
Экспортирование исходников аналогично «svn export»
Отменить все изменения, кроме тех, что уже добавлены в планируемый коммит
Создать новую ветку на сервере из текущей локальной ветки
Восстановить удалённый файл
Сначала нужно найти последний коммит, где файл ещё существует:
Потом восстановить этот файл:
Вернуть один конкретный файл в состояние, в котором он был в каком-либо коммите
Почти как в прошлом примере, только чуть проще:
git checkout идентификатор_коммита имя_файла
Перезапись истории
Неоднократно при работе с Git, вам может потребоваться по какой-то причине внести исправления в историю коммитов. Одно из преимуществ Git заключается в том, что он позволяет вам отложить принятие решений на самый последний момент. Область индексирования позволяет вам решить, какие файлы попадут в коммит непосредственно перед его выполнением; благодаря команде git stash вы можете решить, что не хотите продолжать работу над какими-то изменениями; также можете внести изменения в сделанные коммиты так, чтобы они выглядели как будто они произошли по-другому. В частности, можно изменить порядок коммитов, сообщения или изменённые в коммитах файлы, объединить вместе или разбить на части, полностью удалить коммит — но только до того, как вы поделитесь своими наработками с другими.
В этом разделе вы познакомитесь со способами решения всех этих задач и научитесь перед публикацией данных приводить историю коммитов в нужный вам вид.
Одно из основных правил Git заключается в том, что, так как большую часть работы вы делаете в своём локальном репозитории, то вы вольны переписывать свою историю локально. Однако, как только вы отправите свои наработки, то это уже совсем другая история и вам следует рассматривать отправленные изменения как финальные до тех пор, пока у вас не появится весомая причина что-то изменить. Если кратко, то вы должны воздержаться от отправки своих изменений, пока не будете полностью довольны и готовы поделиться ими со всем миром.
Изменение последнего коммита
Изменение вашего последнего коммита, наверное, наиболее частое исправление истории, которое вы будете выполнять. Наиболее часто с вашим последним коммитом вам будет нужно сделать две основные операции: изменить сообщение коммита или изменить только что сделанный снимок, добавив, изменив или удалив файлы.
Если вы хотите изменить только сообщение вашего последнего коммита, это очень просто:
Эта команда откроет в вашем текстовом редакторе сообщение вашего последнего коммита, для того, чтобы вы могли его исправить. Когда вы сохраните его и закроете редактор, будет создан новый коммит, содержащий это сообщение, который теперь и будет вашим последним коммитом.
Вы должны быть осторожными, используя этот приём, так как при этом изменяется SHA-1 коммита. Поэтому, как и с операцией rebase — не изменяйте ваш последний коммит, если вы уже отправили его в общий репозиторий.
При изменении коммита существует возможность изменить как его содержимое, так и сообщение коммита. Если в коммит внесены существенные изменения, то почти наверняка следует обновить и его сообщение, чтобы оно более точно отражало содержимое коммита.
С другой стороны, если изменения незначительны (исправление опечаток, добавление в коммит забытого файла), то текущее сообщение вполне можно оставить; чтобы лишний раз не вызывать редактор, просто добавьте измененные файлы в индекс и выполните команду:
Изменение сообщений нескольких коммитов
Напомним, что это команда перебазирования — каждый коммит, входящий в диапазон HEAD
Выполнение этой команды отобразит в вашем текстовом редакторе список коммитов, в нашем случае, например, следующее:
Обратите внимание на обратный порядок. Команда rebase в интерактивном режиме предоставит вам скрипт, который она будет выполнять. Она начнет с коммита, который вы указали в командной строке ( HEAD
3 ) и повторит изменения, внесённые каждым из коммитов, сверху вниз. Наверху отображается самый старый коммит, а не самый новый, потому что он будет повторен первым.
Вам необходимо изменить скрипт так, чтобы он остановился на коммите, который вы хотите изменить. Для этого измените слово pick на слово edit напротив каждого из коммитов, после которых скрипт должен остановиться. Например, для изменения сообщения только третьего коммита, измените файл следующим образом:
Когда вы сохраните сообщение и выйдете из редактора, Git переместит вас к самому раннему коммиту из списка и вернёт вас в командную строку со следующим сообщением:
Эти инструкции говорят вам в точности то, что нужно сделать. Выполните:
Измените сообщение коммита и выйдите из редактора. Затем выполните:
Эта команда автоматически применит два оставшиеся коммита и завершится. Если вы измените pick на edit в других строках, то можете повторить эти шаги для соответствующих коммитов. Каждый раз Git будет останавливаться, позволяя вам исправить коммит, и продолжит, когда вы закончите.
Упорядочивание коммитов
Вы также можете использовать интерактивное перебазирование для изменения порядка или полного удаления коммитов. Если вы хотите удалить коммит «Add cat-file» и изменить порядок, в котором были внесены два оставшихся, то вы можете изменить скрипт перебазирования с такого:
Объединение коммитов
С помощью интерактивного режима команды rebase также можно объединить несколько коммитов в один. Git добавляет полезные инструкции в сообщение скрипта перебазирования:
Если вместо «pick» или «edit» вы укажете «squash», Git применит изменения из текущего и предыдущего коммитов и предложит вам объединить их сообщения. Таким образом, если вы хотите из этих трёх коммитов сделать один, вы должны изменить скрипт следующим образом:
Когда вы сохраните скрипт и выйдете из редактора, Git применит изменения всех трёх коммитов и затем вернёт вас обратно в редактор, чтобы вы могли объединить сообщения коммитов:
После сохранения сообщения, вы получите один коммит, содержащий изменения всех трёх коммитов, существовавших ранее.
Разбиение коммита
Git применит последний коммит ( a5f4a0d ) из скрипта, и ваша история примет следующий вид:
И снова, при этом изменились SHA-1 хеши всех коммитов в вашем списке, поэтому убедитесь, что ни один коммит из этого списка ранее не был отправлен в общий репозиторий. Обратите внимание, что последний коммит в списке ( f7f3f6d ) не изменился. Несмотря на то, что коммит был в списке перебазирования, он был отмечен как «pick» и применён до применения перебазирования, поэтому Git оставил его нетронутым.
Удаление коммита
Из-за того, как Git создаёт объекты коммитов, удаление или изменение коммита влечёт за собой перезапись всех последующих коммитов. Чем дальше вы вернётесь в историю ваших коммитов, тем больше коммитов потребуется переделать. Это может вызвать множество конфликтов слияния, особенно если у вас много последующих коммитов, которые зависят от удалённого.
Продвинутый инструмент: filter-branch
Удаление файла из каждого коммита
Установка подкаталога как корневого каталога проекта
Предположим, вы выполнили импорт из другой системы контроля версий и получили в результате подкаталоги, которые не имеют никакого смысла (trunk, tags и так далее). Если вы хотите сделать подкаталог trunk корневым для каждого коммита, команда filter-branch может помочь вам в этом:
Глобальное изменение адреса электронной почты
Эта команда пройдёт по всем коммитам и установит в них ваш новый адрес. Так как коммиты содержат значения SHA-1-хешей их родителей, эта команда изменяет хеш SHA-1 каждого коммита в вашей истории, а не только тех, которые соответствовали адресам электронной почты.
rucreatizer/git
Use Git or checkout with SVN using the web URL.
Work fast with our official CLI. Learn more.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching Xcode
If nothing happens, download Xcode and try again.
Launching Visual Studio Code
Your codespace will open once ready.
There was a problem preparing your codespace, please try again.
Latest commit
Git stats
Files
Failed to load latest commit information.
README.md
Шпаргалка по консольным командам Git
Создать новый репозиторий
Добавление файлов к отслеживанию, индексация отслеживаемых
Убирание файла, папки из отслеживания
Временно переключиться на другой коммит
Переключиться на другой коммит и продолжить работу с него
Потребуется создание новой ветки, начинающейся с указанного коммита.
Удаление файла (просто удалить отслеживаемый файл из папки недостаточно, нужно сделать его неотслеживаемым и отправить коммит)
Перемещение/переименование файлов (Git не отслеживает перемещения/переименование, но пытается его угадать)
Собираем коллекцию простых и сложных примеров работы
Создание нового репозитория, первый коммит, привязка удалённого репозитория с gthub.com, отправка изменений в удалённый репозиторий.
Обычный рабочий процесс
Создание нового репозитория на github.com, клонирование к себе, работа, периодическая «синхронизация с github.com».
Не обязательно после каждого коммита отправлять изменения в удаленный репозиторий, можно сделать это один раз в конце работы.
Внесение изменений в коммит
Работа с ветками
Есть master (публичная версия сайта), хотим масштабно что-то поменять (переверстать «шапку»), но по ходу работ возникает необходимость подправить критичный баг (неправильно указан контакт в «подвале»).
Работа с ветками, конфликт слияния
Есть master (публичная версия сайта), в двух параллельных ветках (branch_1 и branch_2) было отредактировано одно и то же место одного и того же файла, первую ветку (branch_1) влили в master, попытка влить вторую вызывает конфликт.
Синхронизация репозитория-форка с мастер-репозиторием
Есть некий репозиторий на github.com, он него нами был сделан форк, добавлены какие-то изменения. Оригинальный (мастер-) репозиторий был как-то обновлён. Задача: стянуть с мастер-репозитория изменения (которые там внесены уже после того, как мы его форкнули).
Ошибка в работе: закоммитили в мастер, но поняли, что нужно было коммитить в новую ветку (ВАЖНО: это сработает только если коммит еще не отправлен в удалённый репозиторий)
Нужно вернуть содержимое файла к состоянию, бывшему в каком-либо коммите (известна SHA коммита)
При любом действии с github (или другим удалённым сервисом) запрашивается логин/пароль
Речь именно о запросе пароля, а не ключевой фразы.
How can I remove a commit on GitHub? [duplicate]
The community reviewed whether to reopen this question 11 months ago and left it closed:
Original close reason(s) were not resolved
I «accidentally» pushed a commit to GitHub.
Is it possible to remove this commit?
I want to revert my GitHub repository as it was before this commit.
21 Answers 21
Trending sort
Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.
It falls back to sorting by highest score if no posts are trending.
Switch to Trending sort
2 and delete the second line within the editor window that pops up.
Oh, and if your working tree is dirty, you have to do a git stash first, and then a git stash apply after.
That should «undo» the push.
3 instead of HEAD^^^.
For an easy revert if it’s just a mistake (perhaps you forked a repo, then ended up pushing to the original instead of to a new one) here’s another possibility:
Obviously swap in that number for the number of the commit you want to return to.
Everything since then will be deleted once you push again. To do that, the next step would be:
git log to find out the commit you want to revert
git push origin +7f6d03:master while 7f6d03 is the commit before the wrongly pushed commit. + was for force push
Here is a very good guide that solves your problem, easy and simple!
In case you like to keep the commit changes after deletion:
Note that this solution works if the commit to be removed is the last committed one.
You’ll need to clear out your cache to have it completely wiped. this help page from git will help you out. (it helped me) http://help.github.com/remove-sensitive-data/
Delete the most recent commit, keeping the work you’ve done:
Delete the most recent commit, destroying the work you’ve done:
This work for me.
Use git revert for reverting your push.
Revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).
Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset, particularly the —hard option.
To delete the commit from the remote repository:
In order delete the commit from your local repository:
You need to know your commit hash from the commit you want to revert to. You can get it from a GitHub URL like: https://github.com/your-organization/your-project/commits/master
Let’s say the hash from the commit (where you want to go back to) is «99fb454» (long version «99fb45413eb9ca4b3063e07b40402b136a8cf264»), then all you have to do is:
Find the ref spec of the commit you want to be the head of your branch on Github and use the following command:
git push origin +[ref]:[branchName]
In your case, if you just want to go back one commit, find the beginning of the ref for that commit, say for example it is 7f6d03, and the name of the branch you want to change, say for example it is master, and do the following:
git push origin +7f6d03:master
igorsmolin
Базовая работа с коммитами в Git.
Коллеги, приветствую. Сегодня мы немного поговорим о работе с коммитами в системе контроля версиями — Git.
Целью этой статьи является обзор популярных сценариев проблем и методов их решения. Мы узнаем о том, как можно решить проблемы связанные с человеческими ошибками при создании коммитов в Git, какой способ устранения ошибок лучше применять в конкретных ситуациях.
Возникающие проблемы
В ходе разработки каких-либо проектов в Git, мы можем столкнуться с различными ситуациями, такими как:
Безопасные изменения для локального репозитория
Изменить последний коммит
Давайте предположим, что мы работаем над каким-либо проектом локально.
Вдруг мы понимаем, что в момент создания сообщения для последнего коммита мы допустили ошибку, либо сообщение вовсе не подходит. В таком случае выполним команду:
Перед нами откроется текстовый редактор с предложением изменить сообщение. Также мы можем увидеть список файлов которые будут зафиксированы.
Изменим сообщение коммита, выйдем из текстового редактора и проверим историю. Для этого введем команду:
Но что делать, если мы забыли добавить или изменить какие-то файлы в наш последний коммит?
Для этого импортируем нужные файлы в наш проект или изменяем уже существующие и добавляем их в индекс.
Для теста я добавлю файл forgotten file.txt в проект. После этого еще раз выполним команду:
Git сообщит нам, что вновь добавленный файл в индекс будет зафиксирован. Также мы можем переименовать сообщение нашего коммита, как мы делали это ранее. Воспользуемся этой возможностью и изменим сообщение.
В случае необходимости удаления ненужного файла из последнего коммита, мы можем удалить его из проекта, добавить изменения в индекс и воспользоваться все той же командой:
Удалить коммит
Для того, чтобы удалить один или несколько коммитов, мы можем воспользоваться командой git reset. Существует два типа выполнения reset:
Сначала разберем soft reset. Возвращаемся к нашему проекту.
В один момент мы осознали, что допустили ошибку и хотели бы переделать последний коммит.
Для этого выполним команду:
Проверим историю коммитов. Мы можем убедится, что последний коммит был удален.
Файлы, которые были созданы или изменены в удаленном коммите, перешли в состояние рабочего каталога. Мы можем продолжить работу и, например, создать новый коммит на основе этих файлов.
Подобные действия мы можем выполнять для нескольких коммитов сразу. Для примера введем команду:
3 последних коммита пропали из истории.
Проверим состояние файлов, которых коснулась процедура удаления коммитов.
Мы можем полностью удалить коммиты без сохранения связанных с ними файлов. Для этого выполним процедуру hard reset:
И проверим состояние.
Массовое изменение коммитов
Вернемся к нашему проекту и предположим, что настала пора закачать на удаленный репозиторий наши изменения. Безусловно, мы можем выполнять эту процедуру хоть сейчас, однако, мы бы хотели провести небольшую оптимизацию. Например, сократить количество коммитов, исправить ошибки в сообщениях коммитов и т.д.
Для этой задачи хорошо подходит выполнение команды git rebase. Ее запуск в интерактивном режиме позволит нам последовательно сообщить Git’у как бы мы хотели выполнить оптимизацию.
Мы считаем, что 4 последних коммита можно смело объединить в один.
Для этого выполним команду:
Перед нами откроется текстовый редактор по умолчанию в котором мы будем выполнять изменения. Используем коммит с хэшем aab958a как начальный, путем указания команды pick напротив него и укажем напротив трех остальных команду squash. Как мы можем видеть ниже в описании, команда suqash объединит коммит с предыдущим в списке.
После выполнения — выходим из текстового редактора.
Теперь Git попросит от нас ввести сообщения коммитов. Просто для наглядности мы немного переименуем наш объединенный коммит. Также Git сообщит о том, какие файлы подвергнуться изменениям.
Снова выходим из текстового редактора.
Похоже, что наше объединение нескольких коммитов прошло успешно. Давайте проверим это командой:
Мы уже были готовы к публикации наших изменений, однако, посчитали, что необходимо объединить другие 3 коммита в 1 и изменить его сообщение. При этом, мы бы не хотели затрагивать уже объединенный.
Снова вводим команду:
В этот раз в качестве начального коммита будет использоваться с коммит хэшем 4c17043. Для его переименования укажем напротив команду reword. Затем объединяем с ним два последующих коммита командой squash. Последний коммит мы никак не изменяем.
После переименования выходим из текстового редактора и проверяем историю.
Похоже, что нам удалось провести историю коммитов в порядок и теперь нет причин откладывать загрузку нашего проекта на удаленный репозиторий. 🙂
Безопасные изменения для удаленных репозиториев
До этого мы рассматривали случаи локальной разработки. По большому счету, пока мы не публикуем изменения, наши действия — не могут повлиять на деятельность наших коллег по проекту. Применение вышеописанных способов до публикации изменений на удаленном репозитории — вполне оправдано.
Однако, что делать, если мы совместно работаем над проектом и только спустя какое-то время понимаем, что один из коммитов — лишний? Если мы воспользуемся вышеописанными методами, это может спровоцировать ряд проблем в работе над проектом у наших коллег.
В подобных случаях имеет смысл откатывать коммит. Подобная процедура создает еще один коммит, который отменит изменения ненужного. Таким образом мы не порушим историю проекта и избавим наших коллег от лишних проблем.
Снова вовзращаемся к исходному состоянию проекта.
Предположим, что изменения в коммите с хэшем и 5140d80 — лишние. Выполним команду:
Git сообщит нам об изменениях, после отката.
Проверим историю. Как мы можем убедиться, был создан новый коммит, «отменяющий» изменения ненужного.
К сожалению, в реальности могут возникнуть проблемы при откате коммитов, требующие дополнительных мер для их решения. В этой статье мы рассмотрели достаточно простые ситуации, чтобы наглядно увидеть что и как делает каждая команда.
Итоги
В этой статье мы узнали о четырех способах изменять коммиты:
Первые три команды — подойдут для использования в условиях локальной разработки.
Последняя команда — лучший способ, не создавать лишних проблем коллегам при совместной разработке.
Как отменить последнюю фиксацию Git
Иногда при работе с Git вам может потребоваться отменить последнюю фиксацию. Коммит — это моментальный снимок репозитория Git в определенный момент времени. В Git есть ссылочная переменная HEAD которая указывает на последнюю фиксацию в текущей рабочей ветке. Чтобы отменить фиксацию, все, что вам нужно сделать, это указать переменной HEAD на предыдущий снимок.
В этом руководстве объясняется, как отменить последнюю фиксацию Git.
Архитектура Git с тремя деревьями
В Git вы можете отменить изменения, используя команду git reset за которой следует идентификатор фиксации.
git reset принимает дополнительные аргументы, которые позволяют вам управлять поведением команды. Чтобы лучше понять, как работает reset давайте поговорим о трех разных деревьях Git. Архитектура с тремя деревьями — ключевая концепция системы управления Git. Они называются деревьями, потому что представляют собой наборы файлов.
Git управляет следующими тремя деревьями:
Команда git reset имеет три аргумента, которые соответствуют трем деревьям:
Отмена последней фиксации
Измененные файлы сохраняются, но, в отличие от предыдущего примера, теперь изменения не ставятся для фиксации.
Перед выполнением аппаратного сброса убедитесь, что вам больше не нужны изменения.
Отмена нескольких коммитов
С помощью git reset вы можете вернуться к любой предыдущей фиксации.
Например, чтобы переместить текущую ветку на три коммита назад, вы должны использовать:
Команда отобразит список всех коммитов, включая идентификатор и первую строку сообщения о фиксации:
Как только вы узнаете идентификатор коммита, на который хотите выполнить сброс, просто передайте его в команду git reset :
Выводы
Если вы столкнулись с проблемой или хотите оставить отзыв, оставьте комментарий ниже.
Как отменить последний коммит git
Шпаргалка по консольным командам Git
Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит). Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс ( git add ), потом «сохраняем» ( git commit ).
Любой файл в директории существующего репозитория может находиться или не находиться под версионным контролем (отслеживаемые и неотслеживаемые).
Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).
Ключ к пониманию
Ключ к пониманию концепции git — знание о «трех деревьях»:
Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.
У всех коммитов (кроме самого первого) есть один или более родительских коммитов, поскольку коммиты хранят изменения от предыдущих состояний.
Простейший цикл работ
Перед началом работы нужно выполнить некоторые настройки:
Если вы в Windows:
Указание неотслеживаемых файлов
Длинный вывод в консоли: Vim
Узнайте, как отменять изменения в Git с помощью Bitbucket Cloud
Узнайте, как отменить изменения на локальной машине и в репозитории Bitbucket Cloud во время совместной работы с коллегами.
REFLOG ПЕРЕД СБРОСОМ
LOG AFTER RESET
REFLOG FINAL