Git откат изменений: git откатить изменения

git откатить изменения

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

Как известно в git-е существует три сущности:

1. working tree — локальная среда в которой и ведется разработка
2. staging (index) — этап, начинающийся после того как выполнена команда git add
3. HEAD с порядковыми метками — закомиченные изменения

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

git checkout — ИМЯ_ФАЙЛА

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

Команда подтянет изменения из последнего сделанного коммита — содержимого HEAD. Локальные файлы будут замещены.

При этом те, изменения, которые уже были добавлены в индекс с git add в нем останутся.

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

git fetch origin

git reset —hard origin/master

Все данные в индексе и коммиты сбрасываются, состояние восстанавливается из указанной ветки, в примере master.

Самая частая практика при откате изменений git

Можно не трогать индекс и локальные файлы просто удаляя коммиты.

git reflog

reflog выведет все список всех действий

git reset HEAD@{index}

reset возвращает состояние по индексу, взятому из списка

Таким же образом можно отменить последний коммит

git reset HEAD~1

После знака тильды можно указать любое другое число; ~1 означает, что отменяется последний коммит, ~3, что последние три и т.д. Список всех коммитов и комментариев можно увидеть выполнив git log

Другой способ сделать то же

git reset —soft HEAD^

Ключ —soft означает, что данные удалены не будут, только коммит, если заменить его на —hard удалятся и данные

В удаленном репозитории откатить изменения можно таким же образом — убрав последние коммиты, затем выполнив git push с локальной системы на которой ведется разработка.

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

Также читайте про создание собственного git репозитория

Git — Отменить Все Незакоммиченные Изменения

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

Предположим у вас имеются какие-то незакоммиченные изменения и вы хотите все отменить.

В частности, вы хотите удалить все новый файлы и папки, откатить измененные, восстановить удаленные и тому подобное.

Короче говоря, вам необходимо отменить все изменения и вернуться к последнему коммиту.

Дельный Совет: Хотите просмотреть историю изменений какого-то конкретного файла? Узнайте историю коммитов этого файла, историю изменений и вплоть до истории его переименований! Читать далее →

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

Отменить Все Изменения

Уберите из индексации все файлы и директории, которые вы возможно уже проиндексировали с помощью git add:

$ git reset --hard HEAD

Удалить Файлы И Папки Вне Индекса

Хорошая идея: Прежде чем приступать к удалению сначала просто выполните git clean -n, чтобы предварительно просмотреть список файлов и папок которые будут удалены и убедиться в их ненужности.

Дельный Совет: Подзабыли значение какого-то термина в Git? Не беда! Просто прочитайте и добавьте в закладки эту статью! Эта статья →

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

$ git clean -nd
$ git clean -fd

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

Команда выше не удаляет файлы которые перечислены в .gitignore.

Например какие-то билды или временные файлы за которыми обычно Git не следит.

И конечно вы возможно захотите удалить такие файлы тоже.

Внимание! Выполнение следующей команды эквивалентно клонированию репозитория с помощь git clone. Она УДАЛЯЕТ ВСЕ НЕПРОИНДЕКСИРОВАННЫЕ ЛОКАЛЬНЫЕ ФАЙЛЫ, ВКЛЮЧАЯ ИГНОРИРУЕМЫЕ GIT-ом через .gitignore.

Просмотреть, а затем удалить ВСЕ непроиндексированные файлы и папки, включая игнорируемы Git-ом:

$ git clean -ndx
$ git clean -fdx

Git Book — Отмена в Git

Отмена в Git — Сброс, Извлечение и Откат

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

Исправление незакоммиченных ошибок

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

$ git reset --hard HEAD

Это отбросит все сделанные изменения которые вы возможно добавили в индекс git, а также все другие изменения в вашей рабочем дереве. Другими словами, результат этого — вывод команд «git diff» и «git diff —cached» будет пустым.

Если вы просто хотите восстановить только один единственный файл, предположим hello.rb, то выполните git checkout вместо

$ git checkout -- hello.rb
$ git checkout HEAD hello.rb

Первая команда восстановит hello.rb до версии хранящейся в индексе, и команда «git diff hello.rb» не покажет отличий. Вторая команда восстановит hello.rb до версии в ревизии HEAD, таким образом обе команды «git diff hello.rb» и «git diff —cached hello.rb» не покажут отличий.

Исправление закоммиченных ошибок

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

1. Вы создаете новый коммит в котором нет тех нежелательных частей
   присутствующих в старом коммите. Это правильный способ если ваша ошибка уже была опубликована.

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

Исправление ошибки новым коммитом

Создание нового коммита который восстанавливает предыдущее состояние очень просто; нужно только передать команду git revert ссылку на ошибочный коммит; например чтобы восстановить наиболее свежий коммит:

$ git revert HEAD

Это создаст новый коммит который отменяет изменения в HEAD. Вам предоставится шанс отредактировать сообщение-описание нового коммита.

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

$ git revert HEAD^

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

Исправление ошибок изменяя коммит

Если вы только что выполнили коммит но осознали что вам нужно в нем что то исправить, последнии версии git commit поддерживают флаг —amend который указывает git заменит коммит HEAD новым коммитом, основываясь на текущем содержании индекса. Это дает вам удобный случай добавить файлы которые вы забыли добавить или исправить опечатки в сообщении-описании коммита, до того как вы выполните push и сделаете свои изменения доступными всему миру.

Если вы нашли ошибку в давнем коммите, но который еще не опубликовали, используйте git rebase в интерактивном режиме, с «git rebase -i» отмечающий изменения которые требуют коррекции с edit. Это позволит вам изменить коммит во время процесса rebase.

14. Отмена локальных изменений (до индексации)

Цели

• Научиться отменять изменения в рабочем каталоге

01 Переключитесь на ветку Master

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

Выполните:

git checkout master

02 Измените hello.html

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

Внесите изменение в файл hello.html в виде нежелательного комментария.

Файл: hello.html

<html>
  <head>
  </head>
  <body>
    <h2>Hello, World!</h2>
    <!-- This is a bad comment.  We want to revert it. -->
  </body>
</html>

03 Проверьте состояние

Сначала проверьте состояние рабочего каталога.

Выполните:

git status

Результат:

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   hello.html
#
no changes added to commit (use "git add" and/or "git commit -a")

Мы видим, что файл hello.html был изменен, но еще не проиндексирован.

04 Отмена изменений в рабочем каталоге

Используйте команду checkout для переключения в версию файла hello.html в репозитории.

Выполните:

git checkout hello.html
git status
cat hello.html

Результат:

$ git checkout hello.html
$ git status
# On branch master
nothing to commit (working directory clean)
$ cat hello.html
<html>
  <head>
  </head>
  <body>
    <h2>Hello, World!</h2>
  </body>
</html>

Команда status показывает нам, что не было произведено никаких изменений, не зафиксированных в рабочем каталоге. И «нежелательный комментарий» больше не является частью содержимого файла.

Отменить изменения рабочей копии одного файла в Git?

я всегда путаюсь с этим, так что вот тестовый случай напоминания; скажем, у нас есть это bash скрипт для тестирования git:

set -x
rm -rf test
mkdir test
cd test
git init
git config user.name test
git config user.email [email protected]
echo 1 > a.txt
echo 1 > b.txt
git add *
git commit -m "initial commit"
echo 2 >> b.txt
git add b.txt
git commit -m "second commit"
echo 3 >> b.txt

на данный момент изменение не находится в кэше, поэтому git status — это:

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

если с этого момента, мы делаем git checkout в итоге:

$ git checkout HEAD -- b.txt
$ git status
On branch master
nothing to commit, working directory clean

если вместо этого мы делаем git reset результат:

$ git reset HEAD -- b.txt
Unstaged changes after reset:
M   b.txt
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

Итак, в данном случае — если изменения не устроили, git reset нет разница, пока git checkout перезаписывает изменения.

теперь предположим, что последнее изменение из сценария выше поставлено / кэшировано, то есть мы также сделали git add b.txt в конце.

в этом случае git status в этот момент:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   b.txt

если с этого момента, мы делаем git checkout в итоге:

$ git checkout HEAD -- b.txt
$ git status
On branch master
nothing to commit, working directory clean

если вместо этого мы делаем git reset результат:

$ git reset HEAD -- b.txt
Unstaged changes after reset:
M   b.txt
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

Итак , в этом случае-если изменения поставлены, git reset в основном будет вносить поэтапные изменения в неустановленные изменения-while git checkout полностью перезапишет изменения.

Git — Отмена изменений | Atlassian Git Tutorial

В этом разделе мы обсудим доступные стратегии и команды Git для выполнения отмены. Прежде всего необходимо отметить, что в Git не существует традиционной системы отмены, как в текстовых редакторах. Лучше воздержаться от сопоставления операций Git с какой бы то ни было традиционной концепцией отмены изменений. Кроме того, Git имеет собственную систему терминов для операций отмены, и в обсуждении лучше всего использовать их. В числе таких терминов — сброс (reset), возврат (revert), переключение (checkout), очистка (clean) и другие.

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

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

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

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

 git log --oneline e2f9a78fe Replaced FlyControls with OrbitControls d35ce0178 Editor: Shortcuts panel Safari support. 9dbe8d0cf Editor: Sidebar.Controls to Sidebar.Settings.Shortcuts. Clean up. 05c5288fc Merge pull request #12612 from TyLindberg/editor-controls-panel 0d8b6e74b Merge pull request #12805 from harto/patch-1 23b20c22e Merge pull request #12801 from gam0022/improve-raymarching-example-v2 fe78029f1 Fix typo in documentation 7ce43c448 Merge pull request #12794 from WestLangley/dev-x 17452bb93 Merge pull request #12778 from OndrejSpanel/unitTestFixes b5c1b5c70 Merge pull request #12799 from dhritzkiv/patch-21 1b48ff4d2 Updated builds. 88adbcdf6 WebVRManager: Clean up. 2720fbb08 Merge pull request #12803 from dmarcos/parentPoseObject 9ed629301 Check parent of poseObject instead of camera 219f3eb13 Update GLTFLoader.js 15f13bb3c Update GLTFLoader.js 6d9c22a3b Update uniforms only when onWindowResize 881b25b58 Update ProjectionMatrix on change aspect 

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

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

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

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

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

git log --oneline

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

b7119f2 Continue doing crazy things 872fa7e Try something crazy a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt 9773e52 Initial import

Для просмотра коммита «Make some important changes to hello.txt» можно использовать команду git checkout в следующем виде:

 git checkout a1e8fb5

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

 git checkout master

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

Отмена коммита снимка

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

git log --oneline 872fa7e Try something crazy a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt 9773e52 Initial import

Займемся отменой коммита 872fa7e Try something crazy. Возможно, безумный эксперимент зашел слишком далеко.

Отмена коммита с помощью git checkout

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

При наличии открепленного указателя HEAD можно выполнить команду git checkout -b new_branch_without_crazy_commit. Она создаст новую ветку с именем new_branch_without_crazy_commit и совершит переход в это состояние. Теперь репозиторий находится на новой временной шкале, где коммита 872fa7e не существует. На этом этапе мы можем продолжить работу в новой ветке, где коммита 872fa7e не существует и его можно считать «отмененным». Но к сожалению, если вам нужна предыдущая ветка (допустим, master), такая стратегия не подходит. Поэтому рассмотрим другие стратегии отмены. Более детальную информацию и примеры см. в нашей подробной статье о git checkout.

Отмена публичного коммита с помощью git revert

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

 git log --oneline e2f9a78 Revert "Try something crazy" 872fa7e Try something crazy a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt 9773e52 Initial import

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

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

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

 git log --oneline a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt 9773e52 Initial import

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

Отмена последнего коммита

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

Отмена неотправленных изменений

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

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

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

Раздел проиндексированных файлов

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

Отмена публичных изменений

При командной работе в удаленных репозиториях необходимо подходить к отмене изменений с особой осторожностью. Команда git reset, как правило, считается методом локальной отмены. Ее следует использовать при отмене изменений в частной ветке. Она безопасно изолирует удаление коммитов от других веток, которые могут использоваться другими разработчиками. Проблемы возникают, когда команда reset выполняется в общей ветке и затем эта ветка удаленно публикуется с помощью команды git push. В этом случае Git блокирует выполнение команды push и сообщает, что публикуемая ветка устарела, поскольку в ней отсутствуют коммиты, находящиеся в удаленной ветке.

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

Резюме

Мы рассмотрели множество общих стратегий отмены изменений в Git. Важно помнить, что отменить изменения в проекте Git можно несколькими способами. Кроме того, здесь были затронуты и более сложные темы, которые подробно рассматриваются на страницах, посвященных соответствующим командам Git. Наиболее часто используемые инструменты для отмены — это git checkout, git revert и git reset. Вот несколько ключевых моментов, о которых следует помнить.

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

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

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

Откат коммитов на GitHub – Zencoder

Небольшая статья, посвященная вопросу отката коммитов в GitHub.

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

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

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

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

Шаг первый

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

$ git log

Ниже показан краткий вывод команды — четыре самых поздних коммита репозитория:

commit ee3a2ae6888fb87d5013786f6cf3b18da63f7bbb
Author: gearmobile <[email protected]>
Date:   Mon Apr 6 17:48:08 2015 +0300

    End

commit 6d92268e42eace0c78a5150144645333b769623d
Author: gearmobile <[email protected]>
Date:   Mon Apr 6 17:06:35 2015 +0400

    Close to end

commit 855404bf39b5fabd45ba0c6f5702e7a28949a02e
Author: gearmobile <[email protected]>
Date:   Mon Apr 6 15:24:04 2015 +0400

    End 2014-07-16

commit 3eb55145a79f9f8f732338a0e80bd71b2325b6da
Author: gearmobile <[email protected]>
Date:   Mon Apr 6 12:48:17 2015 +0400

    End

Мне нужно вернуть репозиторий из состояния, описанного в коммите , в состояние, зафиксированное в коммите .

Шаг второй

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

Как подробно описывается в статье Отмена изменений в Git, такую задачу можно выполнить командой:

$ git reset --hard 6d92268e42eace0c

где — начальные 16 символов hash-суммы коммита, на который я хочу “перепрыгнуть”. Полный вид hash-суммы в 40 символов можно не использовать — достаточно 16 символов для надежной идентификации конкретного коммита.

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

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

Казалось бы — просто! Достаточно выполнить команду:

$ git push

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

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

Шаг третий

Чтобы заставить Git выполнить обратную задачу — привести удаленный репозиторий к локальному, необходимо использовать ключ .

То есть, форсировать внесение изменений и тем самым “сказать” Git — синхронизировать удаленный репозиторий с локальным репозиторием несмотря на то, что последний имеет более ранюю версию:

$ git push -f

Заключение

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

На этом все,

githubcommit fallback

Откат

в Git — qaru.

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
Общественные вопросы и ответы

2. Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
Программирование и связанные с ним технические возможности карьерного роста

4. Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

Как выполнить откат (сброс) репозитория Git до определенного коммита?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
Общественные вопросы и ответы

2. Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
Программирование и связанные с ним технические возможности карьерного роста

4. Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
Обратитесь к разработчикам и технологам со всего мира

.Откат

— как я могу (просто) отменить изменения в файле в GIT?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
Общественные вопросы и ответы

2. Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
Программирование и связанные с ним технические возможности карьерного роста

4. Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

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

Возможно, вы уже знаете, что Git похож на систему точек сохранения. Первоначально вы обычно изучаете Git, чтобы научиться сохранять свои изменения и фиксировать их в удаленном репозитории. Но как отменить изменение и вернуться в предыдущее состояние?

Об этом мы и поговорим в этой статье.

Я рассмотрел содержание этой статьи в видео, если вам нравится учиться путем просмотра, а не чтения.

Локальное против удаленного

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

Четыре общих сценария

Мы рассмотрим следующие четыре распространенных сценария

1. Отмена локальных изменений
2. Внесение изменений в предыдущую фиксацию
3. Откат к предыдущей фиксации
4. Отмена фиксации, которая была отправлена ​​на удаленный компьютер

Примечание. На снимках экрана ниже я использовал Fork для Mac OS Git Client. Вы можете сделать то же самое в других похожих клиентах Git.

Сценарий 1: Отмена локальных изменений

Первый сценарий — это когда вы создали некоторые изменения. Они еще не совершили. И вы хотите удалить эти изменения.

Допустим, мы хотим создать новую функцию. Мы собираемся добавить в проект немного HTML и CSS:

  
 
`` ''

`` css
/ * В файле CSS * /
.особенность {
  размер шрифта: 2em;
  / * Другие стили * /
}  

Чтобы отменить эти изменения:

1. Перейдите в промежуточную область
2. Выберите файлы, в которых вы хотите отменить изменения
3. Щелкните файлы правой кнопкой мыши
4. Выберите отменить изменения

Сценарий 2: Внесение изменений в предыдущую фиксацию

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

1. Перейти в промежуточную область
2. Подготовить файлы к фиксации
3. Установите флажок «Изменить»
4. Отредактируйте сообщение фиксации
5. Фиксация

Сценарий 3: Откат к предыдущей фиксации

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

1. Зайдите в историю Git
2. Щелкните правой кнопкой мыши фиксацию, которую вы хотите откатить до
3. Выберите сбросить ветку сюда

.