Записки погромиста

1. Перемещаем коммит в другой бранч.

Для того, что бы переместить коммит из одного бранча в другой, например мы по ошибке закомитили в мастер бранч вместо девелопмента, для этого можно воспользоваться командой git cherry-pick <commit hash>, которую мы использовали в первой статье, но проблема в том, что коммит остался в нашем бранче, в котором нам не нужны эти изменения. Для того, что бы избавиться от изменений, нам нужна команда git reset HEAD~1 (или хэш коммита, к которому мы хотим вернуться), но это еще не все, так как у нас остался модифицированный файл. Для того, что бы избавиться от него, воспользуемся командой git checkout <имяфайла>. Если мы сейчас проверим состояние нашего бранча с помощью git status, увидим что наша ветка чиста и в ней нет измененных файлов.

2. Просматриваем старые коммиты и возвращаем состояние HEAD.

Если возникла необходимость вернуться к какому-то коммиту, это можно сделать командой git checkout <commithash> но, если мы проверим git log мы увидим, что HEAD сейчас указывает не на наш бранч, а на коммит и это означет, что если мы сделаем сейчас какие-то изменения в файле, они будут потеряны. Для того, что бы этого избежать, мы создадим новый бранч командой git checkout -b <branch-name> и если мы проверим наш git log сейчас, то увидим, что HEAD указывает на этот бранч, а значит изменения не будут потеряны.

3. Полное удаление  локальных и удаленных бранчей.

После мержа бранча с мастером, мы можем удалить его нажав на кнопку удаления бранча в GitHub. Но, если мы посмотрим на граф командой git log --oneline --graph,  то увидим, что мы просто удалили указатели на эти бранчи, но коммиты по прежнему остались, так что после git branch -vv мы увидим, что git по прежнему уверен, что удаленные бранчи есть в ориджине. Что бы полностью очистить состояние бранчей мы используем команду git remote prune origin. Если мы посимотрим на git branch -vv сейчас, то увидим отметку gone напротив удаленного бранча в ориджине.

Локальные бранч можно удалить командой git branch -d. Обратите внимание, что эта команда вернет хэш, по которому потом этот бранч можно восстановить.

4. Меняем сообщение предыдущего коммита с interactive rebase.

Для этого воспользуемся командой git rebase -i HEAD~3 (3 в данном случае — это количество шагов/коммитов на который мы хотим вернуться назад).  В консоли мы увидим эти самые 3 коммита у которых по умолчанию будет выбрана команда pick. Но так как мы хотим поменять сообщение, вместо pick пишем reword (так как это Vim нажимаем i для вставки текста). Нажимаем :wq для выхода из Вима и нажимаем Enter. После вводим новый текст коммита.

5. Добавляем в .gitignore файл, который уже был запушен.

Например мы решили создать .env файл, но потом увидели, что файл с секретными переменными окружения отправился в наш публичный репозиторий на GitHub. Для удаления этого файла из кэша git воспользуемся командой git rm -r --cached . После нам нужно добавить в коммит только желаемые файлы.

6. Добавлем файл в предыдущий коммит с interactive rebase.

 Если у нас есть коммит, который еще не запушен, но нам нужно добавить в него файл, воспользуемся interactive rebase — git rebase -i HEAD~<количество шагов назад> . Напротив нужного коммита вместо pick пишем edit , нажимаем esq, :wq для выхода из режима редактирования и сохранения файла. Сейчас мы увидим, что находимя в состоянии interactive rebase.  Затем создаем нужный файл, добавляем его в коммит git add <filename> и затем git commit --amend --no-edit,  после чего мы должны увидеть что рабочее дерево чисто и теперь можно git rebase --continue.

7. Объеденям коммиты (squash) перед пушем.

Представим, что у нас есть несколько коммитов, которые мы хотим объединить в один перед пушем для более чистой истории коммитов. Для этого командой git rebase -i HEAD~<количество шагов назад>  запускаем ребейз для коммитов (например для 3-х коммитов HEAD~3). Для этого мы напротив двух коммитов пишем squash вместо pick. После этого можно удалить или оставить старые сообщения коммитов, теперь git status покажет что у нас один коммит вместо трех.