Вернуть рабочую копию в более старый коммит?

Question

Мне нужно вернуть этот репозиторий в коммит e4ea7bf73124968e2f68012f77837df2046fd6e5. Другими словами, я хочу полностью стереть все коммиты, которые появятся после этого.

На основании одного из ответов в этом посте вот что я делаю:

git clone git@github.com:superflycss/utilities-layout.git
cd utilities-layout

git reset e4ea7bf73124968e2f68012f77837df2046fd6e5 
# Moves pointer back to previous HEAD
git reset --soft HEAD@{1}

git commit -m "Revert to e4ea7bf73124968e2f68012f77837df2046fd6e5"

# Updates working copy to reflect the new commit
git reset --hard

В данный момент я думаю, что я свободен дома, но когда я делаю ls, все файлы, которые были в исходном клоне, все еще там. Как будто никакого возврата не произошло вообще. Мысли?

Answer 1

Чтобы вернуться к определенному коммиту, вам просто нужно

git reset --hard <COMMIT_HASH>

В случае, если вы хотите обновить это изменение в удаленном

git push --force origin <BRANCH_NAME>

Если у вас есть неотслеживаемые файлы, посмотрите

git clean

Answer 2

Чтобы достичь того, что вы хотите, с наименьшим изменением того, что вы делаете, переключитесь на следующую последовательность команд:

git clone git@github.com:superflycss/utilities-layout.git
cd utilities-layout

(то же самое, но потом:)

git reset --hard e4ea7bf73124968e2f68012f77837df2046fd6e5

(обратите внимание на добавление --hard здесь), а затем вернемся к тому, что у вас было раньше:

git reset --soft HEAD@{1}
git commit -m "Revert to e4ea7bf73124968e2f68012f77837df2046fd6e5"

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

В исходной последовательности команд для первого шага используется сброс --mixed. Это сбрасывает индекс при записи нового хэша, но оставляет рабочее дерево без изменений. Второй, программный сброс, исправляет сохраненный идентификатор хеша. Третий git reset --hard оставляет неотслеживаемыми файлы рабочего дерева нетронутыми: эти файлы стали неотслеживаемыми в первый git reset и с тех пор не отслеживались. Другими словами, поскольку этот первый сброс был --mixed, эти файлы рабочего дерева никогда не удалялись и теперь не будут.

---

(Примечание: я бы, вероятно, достиг бы этого с помощью одной git read-tree, за которой следовала бы одна git commit, а не несколько git reset команд. Но это другая стратегия, и она не объясняет, что произошло с тем методом, которым вы были используя. Отсюда ответ выше, который объясняет это.)