Комментарии 22
Ребейз на root? Да вы, батенька, извращенец.
Пожалуйста, не пытайтесь это повторить в реальном репозитории. Используйте конкретную базу для ребейза.
В моем случае, когда количество коммитов можно посчитать на пальцах одной руки, то почему бы нет? Но в реальной жизни, возможно, да, не лучший вариант с root.
Количество коммитов это полбеды (но да, в репозитории подобному Linux это будет больно). В вашем варианте будут убраны из истории ветки мерж-коммиты (которых в вашем примере не было, а они будут в реальности), коммиты продублируются. Это в лучшем случае. В худшем вы потеряете изменения, которые были внесены в мерж-коммитах при разруливании конфликтов и сами словите их.
Можно попробовать использовать rebase-merges, однако он гораздо сложнее. В ежедневной практике никто не будет его использовать, это уже исключительные случаи.
Я люблю ребейз и постоянно его использую. Я всегда призываю своих коллег использовать ребейз фичеветок на последний мастер, у нас даже в гитлабе стоит запрет на мерж веток, которые не могут быть смержены через ff.
Однако ваша статья из разряда вредных советов. Если новичок будет выполнять ваши примеры, то в лучшем случае плюнет на все и склонирует репозиторий заново (ведь вы не рассказали как откатить изменения через reflog).
Вам бы стоило рассказать про rebase на конкретный коммит, onto rebase и пожалуй про fork-point (раз уж вы косвенно упомнули force push).
git rebase -i HEAD~2
И вот они, ваши два коммита. Делайте что хотите. Хоть pick, хоть drop.
Аналогично можно с reset провернуть, отмотать на два коммита назад, чтобы код двух коммитов оказался не закоммиченым. И пожалуйста — комитьте как хотите.
reset теряются атрибуты коммита (сообщение, дата, автор), и их потребуется воссоздавать вручную.
Если коммитишь своё, то дата не нужна, автор подставлен автоматически, а сообщение можно вытащить, зная id коммита (а его можно по reflogʼу найти). Копировать не всегда удобно, да (в консоли это значит после вставки удалить 4 колонки), но тоже поправимо (vim умеет из коробки).
Я делал, и в небольших объёмах не страшно. Но лучше, да, использовать другие трюки — например, через git restore накатить состояние рабочей копии по другому коммиту и затем его частично принять.
В А1 продолжать разработку Arithmetic, а в N1 залить коммит N и продолжать разработку
Numerical.
Тогда в N1 будет Arithmetic...
Так суть была в том, чтобы полностью изолировать эти задачи. А так получаем не относящийся к задаче код, это ухудшает понимание у проверяющего. У него на руках будет два mr, в одном из которых половина от другого (и скорей всего уже измененная). И как ему быть? Что из этого он должен считать верным?
то при публикации (git push) git сообщает, что ветка устарела, так как в ней отсутствуют коммиты и отменяет публикацию.
Что-то странное. Оно должно сказать "не fast forward, пушьте насильно или не пушьте".
Но если ветка ушла на публику, да, менять уже поздно. Но обычно и незачем.
Любители rebase based флоу с вами не согласятся
В каком это смысле и кто эти любители, с которыми должен спорить? Я сам предпочитаю ребейз мержу почти во всех случаях, но публичную ветку менять это особый случай и нужна особая мотивация.
Линуксовая манера регулярно ребейзить ветки, из которых берутся коммиты для основных веток (хоть они и публичные) — такой особый случай.
В некоторых компаниях/проектах/командах принято ветки на код-ревью и тесты отдавать в виде готовом к fast-forward с основными ветками. И причёсывать историю после фиксов замечаний-багов. И перед вливанием в основную ещё раз ребейзить. Естественно код-ревью или тесты — это уже не личная ветка.
Естественно код-ревью или тесты — это уже не личная ветка.
Понял, о чём вы. "Публичная" в том смысле, что я вкладывал, это та, которая явно предназначена для того, чтобы из неё брали состояния для своей работы, для регулярных тестов, для сборки релизов. Промежуточные состояния, даже если они предназначены для ревью/тестов/etc., сюда не включаются. И в рабочем репозитории иметь полностью личные ветки, закрытые от остальных, как-то нелепо, поэтому другое понимание тут очень сомнительно.
В некоторых компаниях/проектах/командах принято ветки на код-ревью и тесты отдавать в виде готовом к fast-forward с основными ветками.
Ну у нас в некоторых репах это выставлено в правилах Gerritʼа. И это ничем не мешает по результатам замечаний выкатить K+1-ю ревизию.
Личные ветки для меня личные в том смысле, что не предполагается, что кто-то их будет пуллить, а если будет, то на свой страх и риск. А публичные ровно наоборот, предназначены для того чтобы кто-то их пуллил. И у этого кого-то предполагается минимум квалификации git checkout $branch && git pull не должні вызывать никаких проблем в ежедневном использовании. rebase же вызывает
А публичные ровно наоборот, предназначены для того чтобы кто-то их пуллил.
Тогда это 1:1 с тем, что я говорил.
rebase же вызывает
Ну по крайней мере свои ветки ребейзить — у меня в отделе проблем нет, народ учится очень быстро.
Тогда это 1:1 с тем, что я говорил.
Не совсем, по-моему. Например, для меня моя ветка становится публичной в момент, когда я создаю пулл-реквест без WIP или убираю WIP. Код-ревью, тестирование и т. п. — это уже публичные стадии работы над задачей.
Ну по крайней мере свои ветки ребейзить
Свои вообще личное дело. Проблемы когда ты ветку "шаришь". ВОт банально: отдали ветку мне на код ревью, я её спулили, отревьювил, человек фиксит замечания, но не отдельными коммитами, а правкой существующих. Потом говорит мне, что пофиксил, я опять делаю гит пулл и у меня конфликты, а то и незаметный мерж прошёл с непредсказуемым результатом.
человек фиксит замечания, но не отдельными коммитами, а правкой существующих.
Да, норма.
Потом говорит мне, что пофиксил, я опять делаю гит пулл и у меня конфликты,
А зачем вы делаете pull в этом случае поверх существующего (прошлого) состояния? Единственный нормальный подход при этом — fetch нового состояния без участия своей локальной истории.
Я бы понял, если бы речь шла про какие-то собственные наработки поверх чужой ветки, которая меняется извне, но просто для ревью подобные хитрости тут точно как рыбке зонтик...
Не совсем, по-моему. Например, для меня моя ветка становится публичной в момент, когда я создаю пулл-реквест без WIP или убираю WIP. Код-ревью, тестирование и т. п. — это уже публичные стадии работы над задачей.
Ну вот и непонятно, зачем. Особые случаи, конечно, бывают — когда надо делать свою работу поверх чужой ещё не поступившей в основные ветки — но на то они и особые...
А зачем вы делаете pull в этом случае поверх существующего (прошлого) состояния?
Как говорит git book "an easier or more comfortable workflow". А любители править историю без уведомления всех уже спулливших — ломают этот простой и удобный воркфлоу. И хорошо если поломка пройдёт явно, в виде ошибки, а не что-то там смержится под капотом, а потом запушится.
Как говорит git book "an easier or more comfortable workflow".
Ну тогда таки книгу лечить — что для такого случая даёт кривой рецепт.
Я на такое не попадался — наверно, потому, что там, где пошли подобные сложные действия, воткнули Gerrit. А у него явная подсказка в виде команды "git fetch <длинный путь> && git checkout FETCH_HEAD".
rebase -i в «неправильной» ветке, создать новые «правильные» ветки, и растащить туда коммиты посредством cherry-pick.
Как отменить commit и не облажаться