Как исправить коммит не в ту ветку

Время на прочтение
4 мин

Количество просмотров 36K

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

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

Черт, я сделал что-то не то. Дайте мне волшебную машину времени!

git reflog
# you will see a list of every thing you've
# done in git, across all branches!
# each one has an index HEAD@{index}
# find the one before you broke everything
git reset HEAD@{index}
# magic time machine

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

Я сделал коммит, но сразу же заметил ошибку, ее нужно исправить!

# make your change
git add . # or add individual files
git commit --amend --no-edit
# now your last commit contains that change!
# WARNING: never amend public commits

Команда дает возможность поправить неприятные мелочи — когда вы что-то закоммитили, а потом увидели проблему вроде отсутствующего пробела после знака “=”. Да, есть возможность внести изменения новым коммитом, объединив два варианта при помощи rebase -i. Но это долгий путь.

NB! Никогда не изменяйте коммиты в публичной ветке. Применяйте команду лишь для коммитов в локальной ветке, иначе у вас будут проблемы.

Хочу изменить сообщение последнего коммита!

git commit --amend
# follow prompts to change the commit message

Это просто… глупые требования к оформлению сообщений.

Я случайно закоммитил в мастер, хотя это должен был в новую ветку!

# create a new branch from the current state of master
git branch some-new-branch-name
# remove the last commit from the master branch
git reset HEAD~ --hard
git checkout some-new-branch-name
# your commit lives in this branch now :)

Если вы уже закоммитили в публичную ветку, команды не сработают. В этом случае поможет git reset HEAD@{укажите количество коммитов, на которое нужно вернуться} вместо HEAD~.

Ну вот, я ошибочно закоммитил не в ту ветку

# undo the last commit, but leave the changes available
git reset HEAD~ --soft
git stash
# move to the correct branch
git checkout name-of-the-correct-branch
git stash pop
git add . # or add individual files
git commit -m "your message here";
# now your changes are on the correct branch

Есть еще один способ, который использует большое количество разработчиков — это cherry-pick.

git checkout name-of-the-correct-branch
# grab the last commit to master
git cherry-pick master
# delete it from master
git checkout master
git reset HEAD~ --hard

Мне нужно запустить diff, но ничего не получается

Если вы уверены в том, что изменения были внесены, но diff пустой, вполне может быть, что вы индексировали изменения через add. Поэтому стоит использовать специальный флаг.

git diff –staged

В общем, это не баг, а фича, но она чертовски неочевидная ¯_(ツ)_/¯

Мне срочно нужно отменить коммит, который сделан 5 коммитов назад

# find the commit you need to undo
git log
# use the arrow keys to scroll up and down in history
# once you've found your commit, save the hash
git revert [saved hash]
# git will create a new commit that undoes that commit
# follow prompts to edit the commit message
# or just save and commit

К счастью, не нужно отказываться назад на 5 коммитов, занимаясь копипастом старых и новых файлов. Отменить все это можно при помощи revert.

Кроме того, откатить можно не только коммит, но и целый файл. Правда, это уже будут другие команды…

Отменить изменения в файле

А вот и они, эти другие команды.

# find a hash for a commit before the file was changed
git log
# use the arrow keys to scroll up and down in history
# once you've found your commit, save the hash
git checkout [saved hash] -- path/to/file
# the old version of the file will be in your index
git commit -m "Wow, you don't have to copy-paste to undo"

Когда я впервые нашел эту возможность, это было КРУТО, КРУТО, К-Р-У-Т-О. Но если задуматься — почему именно checkout — лучший вариант для отмены изменений в файле? :shakes-fist-at-linus-torvalds:

Все, я сдаюсь

cd ..
sudo rm -r fucking-git-repo-dir
git clone https://some.github.url/fucking-git-repo-dir.git
cd fucking-git-repo-dir

Спасибо Eric V. За этот способ. И все жалобы по поводу использования sudo адресуйте ему.

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

# get the lastest state of origin
git fetch origin
git checkout master
git reset --hard origin/master
# delete untracked files and directories
git clean -d --force
# repeat checkout/reset/clean for each borked branch

Внимание! Эта статья не является исчерпывающим руководством. И да, есть и другие способы сделать то же самое, причем еще лучше. Но я пришел именно к этим вариантам методом проб и ошибок. Потом у меня появилась сумасшедшая идея поделиться находками. Берите это или уходите!

Комментарий эксперта

Даниил Пилипенко, директор центра подбора IT-специалистов SymbioWay и евангелист бэкенд-направления онлайн-университета Skillbox, дополнил перевод мнением о Git и его актуальности для разработчиков.

Git появился в 2005-ом году, и он далеко не сразу занял рынок. Помню, когда мы ещё в 2008-ом году в команде разработчиков внедряли SVN. И даже в 2012-ом одна близкая ко мне компания усиленно внедряла Mercurial. С годами для многих стало очевидным, что Git — это лучшая система контроля версий, и её теперь используют практически все разработчики.

Если вы начинающий разработчик и собираетесь устраиваться на работу, обязательно изучите Git! Вы должны знать, что такое система контроля версий и зачем она нужна, что такое коммит, ветка, как клонировать репозиторий и отправлять сделанные изменения на сервер, как получать новые изменения с сервера, как делать merge, какие бывают виды “reset”. Поначалу эта тема вам может показаться непонятной и сложной, но вам нужно лишь привыкнуть пользоваться Git, и отвыкнуть вы уже не сможете.

In the common case where you forgot to switch from master to your feature branch before commiting:

git checkout -B feature
git branch -f master origin/master

Replace origin/master with the commit you want your master branch to point to. For example, use HEAD~3 if you want it to point 3 commits behind HEAD, or a1b2c3d if you want it to point to the commit with that hash.

The idea is to recreate the feature branch on the current commit and switch to it. Then make the master branch point to the same commit as origin/master.

General case

In the general case where you want to replay the commits done on master on your feature branch, like the following diagram:

A---B---C---D  $old_master                   A---B---C---D  master
    |                                           |        
    |         G---H---I  master <- HEAD  =>      |         G---H---I
    |                                            | 
    `-E---F  feature                             `-E---F---G'--H'--I' feature <- HEAD

Then cherry-pick the commits you made on master on your feature branch using the following commands. Replace $old_master by the hash of the commit master was pointing to before you made your changes.

git checkout feature
git cherry-pick $old_master..master
git branch -f master $old_master

If needed, stash your local changes using git stash --include-untracked, and then unstash them later using git stash pop.

Without rewriting history

Instead of resetting the master branch into the past, you need to git revert the changes, in addition to cherry-picking the changes on the feature branch.

git checkout feature
git cherry-pick $old_master..master
git checkout master
git revert $old_master..
git checkout feature

Make sure not to git merge your commits into feature. Those changes will be ignored if you try to merge your feature branch back into master, because we just reverted them.

Here’s what the result would look like, with rG, rH and rI the revert commits of G, H and I respectively:

A---B---C---D             rG--rH--rI  master
    |                   /
    |         G---H---I-`
    | 
    `-E---F---G'--H'--I' feature <- HEAD