Очень короткая заметка из серии «Хозяйке на заметку».
Предисловие
У плохо организованных разработчиков, типа меня, часто так бывает, что накомитишь всякого, а потом оказывается что не то и не туда, но git помнит всё и весь этот разгул анархии остаётся в истории.
Мне всегда казалось что это можно исправить, но сколько раз я не начинал искать ответа на этот вопрос — как в git удалить камиты — столько раз мне это не удавалось.
А всё потому что мои поиски приводили меня к rebase, а надо было искать reset.
На мой вкус вопрос недостаточно освещён и моя заметка призвана закрыть этот пробел.
Алгоритм
git branch // смотрим где мы находимся — в какой ветке
git status // проверяем что у нас актуальная версия
git log // ищем камит к которому мы хотим откатиться
sudo git reset --hard 7bcdf46b14b2dacc286b0ad469d5f9022d797f68 // указываем камит начиная с которого нам надо забыть наши изменения, при этом из локальной ветки все камиты с указанного будут забыты — удалены
git push --force origin feature/draft // заливаем локальную ветку в оригинальную (ветку сервера) — из оригинальной ветки будут удалены все «лишние» камиты
Победа !
Если есть более правильный способ, то прошу озвучить в коментах.
PS
На самом деле камиты из репозитория не удаляются, удаляется связь этих камитов с деревом изменений, таким образом эти камиты пропадают из ветки, но git помнит всё.
в документации к гиту легко найти как сделать ресет, но ни где в документации не сказано как после этого изменения в локальной ветке, накатить на удалённую ветку.
польза заметки — не в том что она рассказывает что такое reset, а в том как в origin залить.
Если у вас не было такой проблемы, то я рад за вас.
я не к тому что этого в документации нет, я к тому что не озвучена комбинация reset + push,
товарищам которые из командной строки общаются с git, проблема кажется надуманной,
но есть и другие товарищи которые юзают git через GUI, в gui ( source tree) нет по отдельности push, SourceTree когда видит что у тебя локально камитов недостаёт, предлагает сделать pull и ни какой push --force не предлагается.
но снобам откуда знать о проблемах gui git-клиентов, у них взбурлило, они минуса шлют :)) мой прошлый рекорд всего 12 минусов, тут думаю хотя бы 20 отхвачу, аудитория Хабра не прощает инакомыслия :)
В gui конечно нет кнопок и на половину возможных действий гита и это нормально и правильно, специально для таких случаев есть кнопка «Терминал», которая открывает консоль из которой все это можно сделать.
Мне всегда казалось что это можно исправить, но сколько раз я не начинал искать ответа на этот вопрос — как в git удалить камиты — столько раз мне это не удавалось.
А всё потому что мои поиски приводили меня к rebase, а надо было искать reset.
Вводим в google волшебную фразу «git remove commits from remote branch» вторая ссылка ведет на stackoverflow, и там как раз говорят про сочетание reset + push --force. Более того в статье по первой ссылке тоже это описано в разделе «About History Rewriting» — case 1…
А что же вы гуглили эти два часа? Разве указанный запрос это не ровно то, что вы хотели сделать?
Как то странно выходит, у вас была задача удалить коммиты из удаленной ветки, но вы два часа искали что-то, не вводя в поисковик «удалить коммиты из удаленной ветки», кстати, даже если ввести это на русском, то вторая ссылка приведет на хабр, на статью аналогичную вашей
по старой памяти я гуглил rebase, конечно я два часа не только гуглил но и экспериментировал. не только доки гуглил, но больше примеры. и «задавал» вопросы гуглу с разными формулировками.
когда знаешь ответ на вопрос найти его не сложно :) я бы в другой ситуации.
не дал мне Гугл вашу ссылку на Хабр, если бы дал я бы свой пост не делал.
вы искали в Googl использование команды rebase, а не озвучивали поисковику вашу проблему.
сравните: "git удалить коммиты из удалённой ветки" и "git как с помощью rebase удалить кометы из удалённой ветки".
Проблема преждевременной оптимизации запроса
На Stackoverflow это называют "XY problem". Вместо решения задачи человек ищет решение задачи непременно каким-то инструментом, который ему известен. Оно же: "забиваю гвозди, как правильно держать микроскоп".
Тут не в инакомыслии дело. Просто то, что Вы предлагаете — недопустимо. От слова совсем. Нельзя делать push --force после rebase — таким образом можно порушить работу стороннего человека. При этой операции создаётся отдельная ветка, которая считается HEAD. Rebase можно применять очень осторожно и только локально. Пожалуйста, прочитайте Pro Git, это очень полезная и в то же время интересная книга.
А у вас тестировщики не пуллят код на тестовом серваке после форс пушей на фиксах багов?
Зачем публиковать ветку в центральном репозитории, если ей никто кроме вас не пользуется?
Что эквивалентно откату назад на 5 камитов) Очень удобно так делать) Кстати, лучше не выполнять эту команду через sudo — иначе от суперюзера появятся файлы в проекте, что может в итоге привести к проблемам с правами доступа при работе приложения.
А всё потому что мои поиски приводили меня к rebase, а надо было искать reset.
А почему собственно не rebase,
делаешь git rebase -i HEAD~5 в появившемся редакторе удаляешь нужные
строчки, сохраняешь и выходишь из редактора. Намного же проще чем несколько команд?
Я бы посоветовал удалить вам эту статью. Всё равно она будет набирать только минусы. А кому-то начинающему может стать сборником вредных советов, если он случайно придёт на эту статью из поисковика.
для меня это полезная статья, если люди одно правило применяют ко всем ситуациям то это их проблемы, я выбираю способы в зависимости от условий, в моих условиях это правильное решение.
и если кому то хочется свою ненависть выразить в минусе — сколько угодно. Собака лает, караван идёт.
Именно поэтому и надо постить на StackOverflow, потому что ответ автора заминусуют, он уйдёт вниз, а правильный ответ попадёт наверх. В итоге, случайный посетитель из Google увидит правильный ответ.
Попробую подвести итоги. В статье есть несколько существенных ошибок:
Статья на самом деле решает задачу "как удалить коммиты из локальной ветки, а потом из ветки на удаленном репозитории", но из заголовка и текста этого не понять.
Статья не обучает использованию команды git reset:
Не рассказывает о других популярных вариантах использования: reset без параметров, reset --soft. Да и про reset --hard толком не рассказывает.
Поскольку git reset --hard переписывает историю, обязательно нужно было рассказать 0) как удалять коммиты, не теряя изменения 1) что переписывать историю можно только в своих фиче-ветках, 2) как восстанавливать коммиты с помощью git reflog.
При любом упоминании git push --force нужно подробно рассказывать, куда нельзя и куда можно форс-пушить. Иначе кто-нибудь запушит в master – далеко не везде используется и правильно настроена защита стабильных веток.
Выполнять операции с репозиторием под рутом нельзя, потому что после этого в нем появляются принадлежащие руту файлы (как починить).
комментарии (34)