5.1Отмена

Сравнишь reset и revert по тому, что они меняют в branch, index и working tree. Разберёшь mainline при откате merge и выберешь безопасный способ отмены уже опубликованного изменения.

reset: ветка переезжает, режим решает остальное

Примеры главы идут на Go-сервисе shop. В понедельник, седьмого сентября, Боря завёл репозиторий на сервере, Аня его склонировала. Сервер здесь голый репозиторий в соседнем каталоге, поэтому push показывает адрес ../srv/shop.git, а строки прогресса передачи опущены.

$ git log --oneline
48f0c0f (HEAD -> main, origin/main, origin/HEAD) Сервис заказов
89aa093 Создать модуль shop

git reset <коммит> проходит три дерева по очереди. Сначала записывает текущую вершину в ORIG_HEAD и переставляет на коммит ветку, на которую указывает HEAD. Сам HEAD остаётся привязан к ветке, этим reset и отличается от switch, который переводит HEAD на другую ветку. В detached HEAD (глава 1.2) ветки нет, и переезжает сам HEAD. Дальше режим решает, где остановиться:

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

--soft: коммиты обратно в индекс

Во вторник Аня подняла таймаут записи в main.go, закоммитила, через десять минут подняла и таймаут чтения. На сервер ничего не ушло, и два коммита про одно и то же она хочет склеить в один:

$ git log --oneline
bdd7075 (HEAD -> main) Таймаут чтения тоже
a36d8ba Таймаут записи 5 секунд
48f0c0f (origin/main, origin/HEAD) Сервис заказов
89aa093 Создать модуль shop
$ git reset --soft HEAD~2
$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   main.go
$ git diff --staged
diff --git a/main.go b/main.go
index 7f9e4b7..068f7f9 100644
--- a/main.go
+++ b/main.go
@@ -18,8 +18,8 @@ func main() {
 	srv := &http.Server{
 		Addr:         ":8080",
 		Handler:      newHandler(&Store{db: db}),
-		ReadTimeout:  time.Second,
-		WriteTimeout: time.Second,
+		ReadTimeout:  5 * time.Second,
+		WriteTimeout: 5 * time.Second,
 	}
 	log.Fatal(srv.ListenAndServe())
 }
$ git diff
$ git commit -m "Таймауты сервера 5 секунд"
[main 84b1df3] Таймауты сервера 5 секунд
 1 file changed, 2 insertions(+), 2 deletions(-)

main вернулась на 48f0c0f, а индекс и файлы остались в том виде, в каком их оставил bdd7075. Относительно новой вершины обе правки выглядят добавленными в индекс: diff --staged показывает обе строки, git diff пуст, потому что индекс и диск совпадают. Следующий commit собирает из индекса один коммит. Прежние два никуда не делись, их вершину хранит ORIG_HEAD (git rev-parse --short ORIG_HEAD ответит bdd7075) и reflog (глава 5.2).

commit --amend из главы 2.1 по документации делает примерно то же: reset --soft HEAD^ и коммит. А раз soft не трогает индекс, в склеенный коммит попадёт и то, что лежало в индексе до reset. В опыте, где перед reset --soft HEAD~2 в индекс добавили правку ещё одного файла, git diff --staged --stat показал оба файла. Перед склейкой проверь, что git status чистый.

--mixed: коммит обратно в правки

Следующий коммит вышел сборным: Аня через commit -a отправила в него и проверку id в handler.go, и описание API в README.md. Проверку и документацию лучше разнести, для этого режим по умолчанию возвращает коммит в неразобранные правки:

$ git commit -am "Проверять id заказа"
[main 17f8216] Проверять id заказа
 2 files changed, 9 insertions(+), 1 deletion(-)
$ git reset HEAD~
Unstaged changes after reset:
M	README.md
M	handler.go
$ git status --short
 M README.md
 M handler.go
$ git diff --staged
$ git diff --stat
 README.md  | 4 ++++
 handler.go | 6 +++++-
 2 files changed, 9 insertions(+), 1 deletion(-)

Ветка вернулась на 84b1df3, индекс переписан из него же, и diff --staged пуст. Файлы на диске прежние, поэтому обе правки видны в git diff, а M стоит во второй колонке статуса. Дальше коммиты собираются заново:

$ git add handler.go
$ git commit -qm "Проверять id заказа"
$ git commit -qam "Описать API в README"
$ git log --oneline
1f0321a (HEAD -> main) Описать API в README
3b996bd Проверять id заказа
84b1df3 Таймауты сервера 5 секунд
48f0c0f (origin/main, origin/HEAD) Сервис заказов
89aa093 Создать модуль shop

Файлы, которые добавил отменённый коммит, после mixed становятся неотслеживаемыми: в новом индексе их нет, а на диске они лежат. С флагом -N они останутся в индексе пустыми, как после git add -N из главы 1.3, и попадут в git diff.

--hard: к коммиту целиком

После обеда Аня пробует кэш заказов в памяти. Закоммитила cache.go и поле в store.go, дальше без коммита: тест cache_test.go добавила в индекс, поправила handler.go, завела файл заметок notes.txt, не добавляя в git. Кэш не нужен, и она откатывается к коммиту до опыта:

$ git status --short
A  cache_test.go
 M handler.go
?? notes.txt
$ git reset --hard HEAD~
HEAD is now at 1f0321a Описать API в README
$ git status --short
?? notes.txt
$ git diff HEAD
$ ls -1
go.mod
handler.go
main.go
notes.txt
README.md
store.go

--hard сделал все три дерева равными 1f0321a. Правка в handler.go затёрта, store.go возвращён. cache.go удалён с диска: в HEAD он был, в 1f0321a его нет. Удалён и cache_test.go, хотя он ни разу не попадал в коммит, хватило записи в индексе. Цел только notes.txt: о неотслеживаемых файлах reset не знает. Но и это не гарантия. Неотслеживаемый файл по пути, который есть в целевом коммите, reset перезаписывает молча: в отдельном опыте так пропал черновик c.txt.

Что из потерянного возвращается, видно сразу:

$ git reset --hard ORIG_HEAD
HEAD is now at 90c11e4 Кэш заказов в памяти
$ git status --short
?? notes.txt

Коммит вернулся, с ним и cache.go, а незакоммиченное нет: в статусе снова один notes.txt. Содержимое cache_test.go лежит в базе блобом без ссылок, его туда записал git add, и выловить его можно через git fsck (глава 5.2). Правки в handler.go не было нигде, кроме файла, и её ничем не достать.

Мягче действует --keep. Он тоже переставляет ветку и, как mixed, переписывает весь индекс из коммита, а на диске меняет только файлы, которые различаются в двух коммитах. Если в таком файле есть незакоммиченная правка, он отказывается. Добавленное в индекс остаётся на диске, но уже вне индекса. У Ани правки в README.md, которого опыт не касался, и в store.go, которого касался:

$ git status --short
 M README.md
 M store.go
?? notes.txt
$ git reset --keep HEAD~
error: Entry 'store.go' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'HEAD~'.
$ git restore store.go
$ git reset --keep HEAD~
$ git status --short
 M README.md
?? notes.txt

Первая попытка ничего не тронула, вторая убрала коммит и cache.go, а правку в README.md оставила. Режим --merge нужен в основном, чтобы сбросить индекс с неразрешёнными конфликтами, а merge --abort по документации равен ему (глава 3.1). В отличие от --keep добавленное в индекс он выбрасывает, а новый файл из индекса удаляет и с диска.

Для сравнения тот же git reset HEAD~ из состояния перед откатом, по режиму на копию:

reset с путём: ветка стоит на месте

Правку в README.md Аня откатила, а notes.txt удалила. Вечером она собрала сервис через go build, добавила всё одной командой и закоммитила вместе с правкой в main.go бинарник shop на девять мегабайт:

$ git add .
$ git commit -m "Писать в лог адрес сервера"
[main 766ef00] Писать в лог адрес сервера
 2 files changed, 1 insertion(+)
 create mode 100755 shop
$ git reset HEAD~ -- shop
$ git status --short
D  shop
?? shop
$ git diff --staged --stat
 shop | Bin 9469666 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

С путём reset ветку не двигает и файлов на диске не касается. Он кладёт в индекс версию пути из указанного коммита, по умолчанию из HEAD, и тогда совпадает с git restore --staged из глав 1.3 и 2.2. В HEAD~ бинарника нет, и запись из индекса пропала: для git это удаление, уже внесённое в индекс, а сам файл на диске стал неотслеживаемым. То же делает git restore --source=HEAD~ --staged shop. Режимов у этой формы нет: soft ничего бы не сделал, а hard переписал бы диск, для которого есть restore. Их git отвергает, а --mixed с путём в 2.54 принимает с предупреждением, что запись устарела:

$ git reset --soft HEAD~ -- shop
fatal: Cannot do soft reset with paths.
$ git reset --hard HEAD~ -- shop
fatal: Cannot do hard reset with paths.
$ git commit --amend --no-edit
[main 9123484] Писать в лог адрес сервера
 Date: Tue Sep 8 14:00:00 2026 +0300
 1 file changed, 1 insertion(+)
$ echo shop >> .gitignore

Amend заменил коммит новым, уже без бинарника. Коммит 766ef00 с девятью мегабайтами остался в базе, на него ссылается только reflog, и сборка мусора удалит его, когда запись истечёт (главы 1.4 и 5.2). Так убирают файл, пока коммит не отправлен, а про отправленный четвёртый вопрос.

revert: отмена новым коммитом

В среду Боря поднял лимит соединений с базой с 20 до 100 и отправил коммит, а Аня поверх него отправила свою правку обработчика. К трём часам база упёрлась в max_connections. Коммит уже у всех, и Аня отменяет его новым:

$ git log --oneline -4
42c9c72 (HEAD -> main, origin/main, origin/HEAD) Отвечать 404 только на sql.ErrNoRows
024f0d6 Поднять лимит соединений до 100
f8d1ed3 Не хранить бинарник в репозитории
9123484 Писать в лог адрес сервера
$ git revert --no-edit 024f0d6
[main 53b4670] Revert "Поднять лимит соединений до 100"
 Date: Wed Sep 9 15:00:00 2026 +0300
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git show HEAD
commit 53b4670933156bd68b352aeb8473198e05f0db9b (HEAD -> main)
Author: Аня <anya@example.com>
Date:   Wed Sep 9 15:00:00 2026 +0300

    Revert "Поднять лимит соединений до 100"

    This reverts commit 024f0d6cc066b27ee9b39b2b6bfbd8846df810c8.

diff --git a/main.go b/main.go
index 2c0f274..7420b0a 100644
--- a/main.go
+++ b/main.go
@@ -13,7 +13,7 @@ func main() {
 	if err != nil {
 		log.Fatal(err)
 	}
-	db.SetMaxOpenConns(100)
+	db.SetMaxOpenConns(20)

 	srv := &http.Server{
 		Addr:         ":8080",
$ git push
To ../srv/shop.git
   42c9c72..53b4670  main -> main

Revert берёт изменение коммита, переворачивает и накладывает на текущую вершину слиянием трёх снимков, как cherry-pick: база здесь сам 024f0d6, одна сторона HEAD, другая родитель отменяемого коммита (таблица в главе 3.2). Поэтому правка более позднего 42c9c72 в другом файле цела. Без --no-edit в терминале git откроет редактор с готовым сообщением, и документация советует дописать туда причину. Push прошёл обычной перемоткой: история только выросла.

Если после отменяемого коммита ту же строку успели поменять, слияние упрётся в конфликт. На копии, где лимит после Бори снизили до 50:

$ git revert --no-edit 024f0d6
Auto-merging main.go
CONFLICT (content): Merge conflict in main.go
error: could not revert 024f0d6... Поднять лимит соединений до 100
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git revert --continue".
hint: You can instead skip this commit with "git revert --skip".
hint: To abort and get back to the state before "git revert",
hint: run "git revert --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

В маркерах конфликта вторая сторона подписана parent of 024f0d6. Конфликт разрешают по главе 3.2 и продолжают git revert --continue, передумал отменять, выходи через --abort. Несколько коммитов отменяются диапазоном: git revert --no-edit A..B создаёт по коммиту на каждый, начиная с самого нового, а с --no-commit все обратные правки копятся в индексе для одного общего коммита.

По документации revert требует чистой рабочей копии. На деле git 2.54 пропустил правку в файле, которого отмена не касается, а отказал только при правке в индексе или в том же файле.

revert merge-коммита: -m 1

В четверг Аня сделала ветку retry: withRetry в новом retry.go, обёртка вокруг обоих запросов в store.go и логирование попыток. Боря влил ветку с --no-ff и отправил:

$ git log --oneline --graph -6
*   66c2b9a (HEAD -> main, origin/main, origin/HEAD) Merge branch 'retry'
|\
| * dd31b37 (origin/retry, retry) Логировать повторы
| * 8f664fc Повторять запросы к базе
* | fc0a712 Проверять DATABASE_URL при старте
|/
* 53b4670 Revert "Поднять лимит соединений до 100"
* 42c9c72 Отвечать 404 только на sql.ErrNoRows

К четырём часам посыпались ошибки duplicate key: INSERT доходил до базы, ответ терялся по таймауту, и withRetry вставлял тот же заказ второй раз. Боря убирает ветку целиком:

$ git revert 66c2b9a
error: commit 66c2b9a0fa5d63d2d8ddc0bb11fdeaf65b18a099 is a merge but no -m option was given.
fatal: revert failed
$ git revert -m 1 --no-edit 66c2b9a
[main acc2005] Revert "Merge branch 'retry'"
 Date: Thu Sep 10 16:00:00 2026 +0300
 2 files changed, 5 insertions(+), 30 deletions(-)
 delete mode 100644 retry.go
$ git show HEAD --stat
commit acc20056ceeeb890fc19113a813a097269a4239d (HEAD -> main)
Author: Боря <borya@example.com>
Date:   Thu Sep 10 16:00:00 2026 +0300

    Revert "Merge branch 'retry'"

    This reverts commit 66c2b9a0fa5d63d2d8ddc0bb11fdeaf65b18a099, reversing
    changes made to fc0a71285547c5e41587dbbf05687ec707590365.

 retry.go | 21 ---------------------
 store.go | 14 +++++---------
 2 files changed, 5 insertions(+), 30 deletions(-)

У обычного коммита один родитель, и его изменение считается относительно него. У слияния родителей два (порядок разобран в главе 1.2), и изменений тоже два: относительно fc0a712 слияние принесло ветку retry, а относительно dd31b37 то, что появилось в main. Какое отменять, git не угадывает. -m 1 объявляет основной линией первого родителя, и отменяется всё, что пришло из ветки. На копии -m 2 отменил проверку DATABASE_URL из main и оставил повторы, а такое нужно редко. Кнопка Revert у влитого merge request в GitLab делает тот же revert слияния сразу или через новый merge request, на GitHub через новый pull request.

Файлы вернулись к состоянию до слияния, а граф нет:

$ git branch -a --merged
* main
  retry
  remotes/origin/HEAD -> origin/main
  remotes/origin/main
  remotes/origin/retry
$ git merge retry
Already up to date.

8f664fc и dd31b37 по-прежнему предки main. Revert отменил данные, но не историю, и для git ветка остаётся влитой.

Повторное слияние и revert the revert

В пятницу Аня чинит ветку: вставку заказа повторять нельзя, повторы остаются только у чтения.

$ git diff
diff --git a/store.go b/store.go
index 86587bf..0f3069b 100644
--- a/store.go
+++ b/store.go
@@ -24,9 +24,7 @@ func (s *Store) Find(ctx context.Context, id int) (Order, error) {
 }

 func (s *Store) Create(ctx context.Context, o Order) error {
-	return withRetry(ctx, func() error {
-		_, err := s.db.ExecContext(ctx,
-			"INSERT INTO orders (id, total) VALUES ($1, $2)", o.ID, o.Total)
-		return err
-	})
+	_, err := s.db.ExecContext(ctx,
+		"INSERT INTO orders (id, total) VALUES ($1, $2)", o.ID, o.Total)
+	return err
 }
$ git commit -qam "Не повторять вставку заказа"
$ git push -q

Коммит 9abef44 ушёл на сервер. Аня переключается на main, забирает вчерашние слияние и revert и вливает исправленную ветку:

$ git merge-base main retry
dd31b374e95f3c1a03c25897fe42ee46bb934672
$ git merge --no-edit retry
Auto-merging store.go
Merge made by the 'ort' strategy.
$ git diff --stat HEAD^1 HEAD
$ git grep -n withRetry

Слияние прошло без конфликтов и не поменяло ни строчки. Общий предок у веток dd31b37, вершина retry до починки: в ней есть и retry.go, и обе обёртки. Со стороны main revert удалил файл и обе обёртки. Со стороны retry убрана одна обёртка, у Create, и ровно так же, как её убрал revert. Трёхстороннее слияние (глава 3.1) берёт изменения обеих сторон, а они сходятся в одно: повторов нет нигде. Сборка проходит, ветка «влита», а фичи в main нет. Так тихо бывает не всегда (вопрос 3).

Слияние ещё не отправлено, поэтому Аня убирает его reset-ом, отменяет revert и только потом вливает ветку:

$ git reset --hard ORIG_HEAD
HEAD is now at acc2005 Revert "Merge branch 'retry'"
$ git revert --no-edit acc2005
[main f81fac8] Reapply "Merge branch 'retry'"
 Date: Fri Sep 11 10:40:00 2026 +0300
 2 files changed, 30 insertions(+), 5 deletions(-)
 create mode 100644 retry.go
$ git grep -n withRetry
retry.go:11:func withRetry(ctx context.Context, op func() error) error {
store.go:19:	err := withRetry(ctx, func() error {
store.go:27:	return withRetry(ctx, func() error {
$ git merge --no-edit retry
Merge made by the 'ort' strategy.
 store.go | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
$ git grep -n withRetry
retry.go:11:func withRetry(ctx context.Context, op func() error) error {
store.go:19:	err := withRetry(ctx, func() error {
$ git push
To ../srv/shop.git
   acc2005..0bff74a  main -> main

Revert отката вернул в main всё, что приносило первое слияние, вместе с ошибкой. Теперь со стороны main обёртки на месте, и новое слияние честно применяет правку из 9abef44. Сообщение Reapply "…" вместо Revert "Revert "…"" git пишет с версии 2.43, и документация просит переписать его своими словами: через месяц цепочка «вернули, откатили, вернули» без объяснения не читается. Тот же случай разобран в документации git, в заметке «How to revert a faulty merge» Линуса Торвальдса и Джунио Хамано.

Что можно отменять после push

Разница между reset и revert видна, когда коммит уже у других. Вернёмся в среду, на копии репозиториев. Коммит Бори с лимитом соединений лежит на сервере, Аня его забрала и закоммитила поверх свою правку, но не отправила. Боря решает убрать коммит reset-ом:

$ git reset --hard HEAD~
HEAD is now at f8d1ed3 Не хранить бинарник в репозитории
$ git push
To ../srv/shop.git
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to '../srv/shop.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git push --force-with-lease
To ../srv/shop.git
 + 024f0d6...f8d1ed3 main -> main (forced update)

У Ани:

$ git pull
From ../srv/shop
 + 024f0d6...f8d1ed3 main       -> origin/main  (forced update)
Already up to date.
$ git push
To ../srv/shop.git
   f8d1ed3..42c9c72  main -> main
$ git log --oneline -3 origin/main
42c9c72 (HEAD -> main, origin/main, origin/HEAD) Отвечать 404 только на sql.ErrNoRows
024f0d6 Поднять лимит соединений до 100
f8d1ed3 Не хранить бинарник в репозитории

Для ветки Ани origin/main просто отъехал назад: всё, что там есть, в её main уже лежит, вливать нечего. Её push оказался обычной перемоткой и вернул 024f0d6 на сервер. С pull.rebase=true вышло бы наоборот: rebase по reflog origin/main понял бы, что коммит пришёл с сервера (выноска про fork-point в главе 4.1), и молча выбросил бы его из ветки Ани. В обоих случаях судьбу коммита решила настройка у коллеги, а не тот, кто отменял. Revert такой развилки не создаёт: отмена приходит к каждому обычным коммитом при следующем pull.

Из последнего столбца есть исключение: свою ветку merge request, на которой никто не строит, переписывают и отправляют через --force-with-lease (глава 4.1).

$ git rebase --no-ff 53b4670
Current branch retry is up to date, rebase forced.
Successfully rebased and updated refs/heads/retry.
$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
$ git merge --no-edit retry
Merge made by the 'ort' strategy.
 retry.go | 21 +++++++++++++++++++++
 store.go |  6 ++++--
 2 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 retry.go

Что стоит запомнить

• reset двигает текущую ссылку и в зависимости от режима меняет index и working tree.
• revert создаёт новый commit с обратным изменением.
• Для revert merge-коммита нужно выбрать mainline parent через -m.

Частые ошибки

• reset --hard может удалить незакоммиченные изменения.
• Revert merge влияет на будущие повторные слияния этой ветки.

# copy 1
git reset --soft HEAD~1
# copy 2
git reset --mixed HEAD~1
# copy 3
git reset --hard HEAD~1

git reset --hard HEAD~1
git push --force origin main