Закоммитил не в тот брэнч

7 2

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

Проблема популярная и решается очень легко. Нужно узнать SHA последнего изменения, которое вы хотите оставить. Для этого я предпочитаю использовать команду gitk, которая показывает изменения в виде дерева. На картинке к этому посту список изменений наверху слева. Находите последний коммит, который должен остаться и запоминаете (копируете) его SHA. 

В Windows gitk кажется идет по умолчанию с установкой git, по крайней мере мне ни разу не приходилось устанавливать эту утилиту. На маке ее нет, но gitk на macOS можно установить следующей командой:

brew install git

Можно еще перед выполнением команды install на всякий пожарный выполнить update. 

brew update

Но вернемся к нашей проблеме, когда коммит был совершен не в тот брэнч. Теперь выполняем команду:

git reset --soft d0da8563e….

В данном случае d0da8563e – это sha, который мы запомнили. 

Указатель текущего коммита перейдет именно на d0da8563e, а все изменения, которые были после перейдут в состояние stage. 

Теперь можно пушнуть текущее состояние с помощью команды: 

git push -f

где -f указывает на то, что мы хотим форснуть команду, это необходимо, иначе данные не пойдут в репозиторий. Без флага -f попытка завершиться ошибкой, нам скажут, что на сервере есть данные, которые мы можем потерять. 

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


Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку уже лайкнули 2 человек


Комментарии

IDDQD

08 Января 2020

Будет работать только если никто не пушанул новые (необходимые изменения) в тот же самый бранч. Обычный git revert тут справится лучше.


Михаил Фленов

08 Января 2020

Согласен, если кто-то уже пушнул, то тут уже немного другая история. Придется лишний коммпит вытаскивать в другой брэнч с помощью cherry-pick и ревертить коммит. Чаще все же народ сразу замечает, что пушнули не туда, когда создают pull request.


IDDQD

09 Января 2020

Why cherry-pick..? Просто git revert ошибочный коммит и push. Конечно, в истории остануться эти два изменения, но это лучше чем переписывать историю с push --force или изменения с cherry-pick.


Михаил Фленов

09 Января 2020

Проблема в том, что закомитил не в тот бренч. Коммит верный, код верный, но он должен был быть в другом бренче. Например, у тебя два бренча в работе:

wip/redesign
wip/bugfix784747

Ты зафиксил баг и по ошибке взял и закоммитил его в redesign, а должен был в wip/bugfix784747. Ты просто откатываешь немного историю назад wip/redesign и коммитишь туда, куда нужно. Если закоммитил вообще не то, то тут конечно реверт и забыли про косячный коммит.


Пикачу

10 Января 2020

Так можно делать, если это ваша ветка с задачей. С каким-нибудь master или релизной веткой вообще надо запрещать подобные действия с force push.


Михаил Фленов

10 Января 2020

105%


IDDQD

10 Января 2020

Странные народ - коммитить не в тот бранч да еще делать это неоднократно...


Добавить Комментарий

Еще что-нибудь

Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.

О блоге

Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю

Обратная связь

Без проблем вступаю в неразборчивые разговоры по e-mail. Стараюсь отвечать на письма всех читателей вне зависимости от страны проживания, вероисповедания, на русском или английском языке.

Пишите мне