Comments 22

Ребейз на root? Да вы, батенька, извращенец.


Пожалуйста, не пытайтесь это повторить в реальном репозитории. Используйте конкретную базу для ребейза.

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

Количество коммитов это полбеды (но да, в репозитории подобному Linux это будет больно). В вашем варианте будут убраны из истории ветки мерж-коммиты (которых в вашем примере не было, а они будут в реальности), коммиты продублируются. Это в лучшем случае. В худшем вы потеряете изменения, которые были внесены в мерж-коммитах при разруливании конфликтов и сами словите их.
image
Можно попробовать использовать 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 накатить состояние рабочей копии по другому коммиту и затем его частично принять.

Предложение «декомпозировать задачи заранее», не очень практичное, на мой взгляд. Что плохого в том, чтобы наследовать 2 новые ветки из коммита А: А1 и N1?
В А1 продолжать разработку Arithmetic, а в N1 залить коммит N и продолжать разработку
Numerical.

Так суть была в том, чтобы полностью изолировать эти задачи. А так получаем не относящийся к задаче код, это ухудшает понимание у проверяющего. У него на руках будет два mr, в одном из которых половина от другого (и скорей всего уже измененная). И как ему быть? Что из этого он должен считать верным?

то при публикации (git push) git сообщает, что ветка устарела, так как в ней отсутствуют коммиты и отменяет публикацию.

Что-то странное. Оно должно сказать "не fast forward, пушьте насильно или не пушьте".
Но если ветка ушла на публику, да, менять уже поздно. Но обычно и незачем.

В каком это смысле и кто эти любители, с которыми должен спорить? Я сам предпочитаю ребейз мержу почти во всех случаях, но публичную ветку менять это особый случай и нужна особая мотивация.
Линуксовая манера регулярно ребейзить ветки, из которых берутся коммиты для основных веток (хоть они и публичные) — такой особый случай.

В некоторых компаниях/проектах/командах принято ветки на код-ревью и тесты отдавать в виде готовом к 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.
Only those users with full accounts are able to leave comments. Log in, please.