Я вроде бы уже спрашивал, но что-то не нашел у себя заметок на эту тему. Все чаще вижу, что люди везде и всюду используют #git #rebase вместо #git #merge.

tl;dr Нужен очень подробный и детальный мануал по переезду с merge на rebase.

У всех основная и чуть ли не единственная причина использования rebase - красота истории. Меня красота истории не волнует, меня полностью устраивает линейность и последовательность merge. Я несколько раз пробовал использовать rebase, но это вызывает то фантомные боли, то утерянные изменения. И оказывается, что для красоты истории надо прикладывать усилия с перемещениями и сжатиями коммитов. В моем мировоззрении все только в пользу merge. В заметках осталась ссылка о том, что merge полезнее, но сайт больше не доступен - https://itnan.ru/post.php?c=1&p=340558

Но я в очередной раз наткнулся на фразу "я перешел на сторону тех, кто использует только rebase" и в очередной раз хочу попробовать rebase. Но мне нужен очень хороший разбор что делать в ситуации А, а что делать в ситуации Б. Хочу выработать новую привычку в разработке, но самостоятельно не получается. Базовые сравнения merge vs rebase, которые легко гуглятся, мне не помогают.

Находил статью по использованию rebase update-ref, там реально интересные случаи описаны и полезная причина использовать так https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/

В общем @tech помогай, пожалуйста.

@sattellite @tech так или иначе тебе придётся писать внятные коммиты, либо в момент ручного ребейза, либо при сквоше. Я не люблю в мастере кучу невнятных промежуточных коммитов. В процессе ревью часто приходится что-то править и информация в месседже первых комиитов может устареть.

Но есть ещё один нюанс, в масштабных реквестах иногда удобнее ревьюить по коммитам. И из уважения к ревьюеру удобная для чтения история в такой ситуации нужна до squash. Короче, я отношусь к rebase как к способу точечно сгруппировать коммиты, эдакий --amend на максималках. Использую не всегда.

@strizhechenko @sattellite @tech никогда не пойму людей что по комитетам смотрят историю.

Для меня это как три месяца спички считать а потом написать письмо на завод.

Вот тебе дали большой мр - смотри его кусками.

@kurator88 @sattellite @tech я частенько из блейма попадаю в коммит, в котором узнаю, а нахрена я именно так сделал. Код лучшая документация, но намерения и причины одним лишь неймингом не описать.

@strizhechenko @sattellite @tech ну так фича у меня входит в мастер одним комитом где в сообщении к комиту есть номер истории по которой я могу поднять все ниточки.

@kurator88 @sattellite @tech хаха, никогда не работал достаточно долго, чтобы проебали/промигрировали весь таск трекер?)

@strizhechenko @kurator88 @tech у меня только на текущем проекте сейчас уже 4-й или 5-й тасктрекер. Меня ругают и говорят не писать ишью в гитлабе, не тратить время на эту глупость. по итогу гитлаб под моим руководством и в нем все хранится с 2015 года. Только не все ишью в нем есть

@sattellite @kurator88 а теперь зацени плюху моей схемы работы. Прикинь, гитлаб и таск-трэкер скопытились, например вместе со всеми бэкапами, не знаю, метеорит прилетел в (оба? оба ведь?) ДЦ.

В моём случае отстроить исторический контекст заново можно _просто запушив репу_ в новый большой русский гитлаб. Даже импорт мерж-реквестов не требуется.

Ну и я ещё (сейчас уже в 100 раз реже) иногда люблю поработать в оффлайне. С моим подходом - всё своё ношу с собой. Гитлаб и таск-трэкер, я наверное, с собой не понесу. :)

@strizhechenko вся история читается из сообщений в main?@kurator88

@strizhechenko @sattellite наверное это сработает на одной царской монорепе.

У нас сейчас 46 микросервисов на 3 человек, без нормальной документации и арх. ревью не выжить. А если мы все равно будем писать в конфлю то зачем тратить время на гитлаб ?

@sattellite @kurator88 ну, не вся, понятное дело. Переписки и срачи на 240 сообщений туда не включаются, но я обычно стараюсь перед мержем включить в коммит-месседж их итог.

@kurator88 @strizhechenko @tech В случае с ребейзом ты увидишь "красивый" коммит. Тогда надо писать комментарии и в самом коде.

@sattellite @strizhechenko @tech

мне кажется документировать решение в МР странной практикой ( не встречал ранее и видимо поэтому странная )

@sattellite За последние 10+ лет везде и всюду серьёзные проекты отказывались от rebase в пользу merge.
На хабрах-швабрах полно публикаций такого рода о вредности и глупости rebase. Была и такая, в которой наглядно демонстрировалась не только потеря контекста, но и нарушение логики работы кода из-за rebase. Это понятно профессионалам, сталкивающимся с подобным, но выглядит стрёмным утверждением для молодых и неопытных. Если надо, то можно найти и ту публикацию.

Хорошо показывает себя рабочий процесс на базе схлопывания множества коммитов через сквошинг до нескольких атомарно значимых в одном pull request \ merge request. А так же чери-пиккинг подобных атомарных коммитов между ветками. В комментариях к таким коммитам указываются сквозные идентификаторы ишьюсов и тасок из различных систем баг треккинга или управления жизненным циклом задач (тасок).

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

Не важно большие моно-репы используются или множество разных с сабмодулями. Как бы ни организовывалась кодовая база на две-три сотни микросервисов, а всё равно rebase нельзя использовать.

@grumb я того же мнения. Сквошинг использую как раз при мердже в главную ветку. В общем остаюсь на мердже

@sattellite вот публикация «Чем опасен rebase, или как получилось, что 2*3=5»

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

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

@grumb какая прикольная статья.

@sattellite закинул через боты ретрансляторы и почти наверняка срач начнётся\подымется :)
можно как перекличку использовать, кто реально профи бывалый, а кого случайно ветром надуло в «разработку» :)

@sattellite и раз срача нету. то значит фанаты rebase знают правду и просят не беспокоить всякими фактами из жизни неудачников :)

@grumb видимо так