Этап 8 - История Git, восстановление и продвинутые инструменты
К этому моменту команда уже использует PR и слияния. Продвинутые инструменты начинаются тогда, когда всё ещё нужно исправить последствия ошибки или временно отложить незавершенную работу.
revert и reset — не одно и то же
Предположим, в task-service какой-то commit оказался ошибочным.
git revert создаёт новый commit, который отменяет эффект предыдущего. Это безопасно для общей ветки.
git reset перемещает указатель текущей ветки; это меняет локальную историю.
Для опубликованной ветки обычно выбирают revert:
git revert <commit-hash>
Для локальной корректировки до push можно использовать reset:
git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1
С --hard удаляется рабочая незакоммиченная часть, поэтому будьте внимательны.
Возврат после ошибочного перемещения
git reflog хранит недавние перемещения HEAD:
git reflog
git switch -c recovery-branch <lost-commit-hash>
Даже если commit оказался «терянным», его нередко удается найти через reflog.
Stash как временная полка
Когда нужно срочно переключиться на другой task:
git stash push -m "WIP: task-service ordering tweak"
git switch main
git pull
git stash pop
Stash — временный контур, не заменитель веток или коммитов.
Cherry-pick для точечной передачи
Если в другой ветке есть хороший фикс, а в вашу ветку нужно перенести только его:
git cherry-pick <commit-hash>
Это лучше, чем мердж всей feature-ветки, когда нужен один commit.
| Инструмент | Когда применять |
|---|---|
revert | Исправить опубликованную ошибку безопасно |
reset | Подчистить локальную историю до push |
reflog | Найти недавние положения HEAD и восстанавливать |
| ссылки | |
stash | Отложить незавершенную работу |
cherry-pick | Перенести один commit между ветками |
Практика для надежности команды
Перед reset всегда проверяйте: commit уже в общем доступе или нет. Если коммит уже опубликован, правильнее использовать revert, чтобы коллеги не столкнулись с внезапным пересозданием истории.
stash удобно хранить временно, но после stash pop всегда смотрите итоговый diff и сразу коммитьте если изменения действительно нужны. Иначе легко потерять нити в рабочих сценариях.
cherry-pick — точечный инструмент и полезен для одного фикс-коммита. Если переносите цепочку логики, лучше объясняемый merge даст чище историю, чем серия случайных cherry-pick.
План на случай production-инцидента
Если в task-service попал регресс, сначала используйте git log и git status для установления точки. Для уже опубликованной ошибки выбирайте revert, публикуйте фикс, а уже затем разберите root cause.
reflog и stash не магия, а вспомогательные механики: они помогают не потерять рабочую последовательность, но все равно требуют аккуратного описания в коммитах и PR.