Как стать автором
Обновить

Комментарии 18

поэтому убедитесь в том, что делаете!

Ммм, что это означает?
Rebase — это то что нельзя делать.
Статья ни о чём — rebase (интерактивный) можно и нужно использовать для наведения порядка (собрать коммиты в осмысленные и законченные коммиты) в своей ветке перед мерджем как бы он ни выполнялся, также rebase разумно использовать для синхронизации своего форка/ветки с главной веткой чтобы не иметь мусора про мерджи в истории.
А вот мердж в мастер уже скорее стоить делать именно merge'ем, во всяком случае если вы не гуру гита.
Из-за стремительного уменьшения относительной доли гуру гита среди пользователей гита уже давно набирает популярность squash merge, когда в master ваша ветка всегда попадает в виде одного коммита.
А чем адепты squash merge аргументируют свой подход? Типа раз никто не следит за своей историей коммитов, то вместо наведения порядка тупо «округлим» её до коммита на фичу?
некоторые contribution считают под количеству коммитов, поэтому 1 фича — 1 коммит. что в целом не так-то уж и плохо

Я не то, чтобы адепт, но плюсы есть:


  • Стимулирует делать в одной ветке одну задачу.
  • При следовании спеке Conventional Commits получаем чистые и полезные описания всех коммитов в master, при этом над описаниями коммитов в фиче-бранчах можно не париться (ибо зачастую их в принципе невозможно контролировать, напр. когда получаешь сторонний пул-реквест на гитхабе).
  • Упрощает revert при проблемах.
  • Упрощает bisect.

А вот явных минусов особо не видно. Да, теряется пошаговая история как кто-то пилил фичу и лажал в процессе — ценность этой истории после мержа фичи обычно нулевая. Если будет очень надо — в течении месяца её можно будет ручками восстановить из reflog.

Да, типа того.


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


Это может бесить людей, которые заморачиваются с разбиением на логические куски, с нормальными описаниями, возможностью сделать bisect и revert… — когда вся эта красота выбрасывается squash. Но когда твой средний пулл-реквест выглядит так — и люди искренне не понимают, что в этом плохого, так как единицей ревью и работы является пулл-реквест, а не коммит — уж лучше squash, чем эти сообщения сохранять в истории.


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

Это отличный способ если мерджатся изменения которые имеет смысл иметь в виде одного коммита.
Rebase — еще один способ перенести изменения из одной ветки в другую. Rebase сжимает все изменения в один «патч». Затем он интегрирует патч в целевую ветку.

Rebase не изменяет целевую ветку, он «переигрывает» изменения из текущей ветки на вершине целевой ветки, оставаясь в текущей ветке. Для интеграции изменений вам все равно прийдется сделать merge. Однако поскольку в целевой ветке более не будет изменений, сделанных после точки отбранчевания, мердж будет проведен как fast forward, что означает перенесение маркера вершины целевой ветки на конец текущей ветки без merge-комита.

Я понимаю, что возможно, я придираюсь к словам, и в результате происходит ровно то, что вы и описали. Но эти неточности в понимании тонкостей работы git только вредят. И лишний раз приводят к спорам, что лучше, merge или rebase, хотя это вообще в принципе разные функции!
Да, это описание гораздо лучше, чем то, что в статье.

На мой взгляд rebase очень удобен только при работе в своей feature ветке для выравнивания с общей (develop) веткой. С shared ветками довольно проблематично, учитывая, что в среднем многие разработчики не очень сильно разбираются в таких тонкостях, проще просто не создавать проблем коллегам и просто использовать merge. Вливание в основную ветку у нас в целом заведено делать через megre с опцией —no-ff.

Статья, к сожалению, слишком поверхностна, чтобы быть полезной. К тому же, она только больше запутывает в механизмах git.
В целом, rebase существенно более мощный и многофункциональный инструмент, чем просто merge. Но обратной стороной является то, что им так же легко репозиторий привести к испорченному состоянию.

Что было бы полезно — сделать какую-то основательную статью с анализом всех популярных подходов к git flow и их подводных камней. В частности, в реалиях наличия ci/cd (когда мы хотим недоделанный код катить и сразу видеть результат его выполнения, кстати, ребейз в этом случае чреват ещё дополнительными рассинхронами с теми же средствами сборки и хранения артефактов)

За перевод спасибо, каких-то сильных ляпов в нем не нашел, но особо и не вчитывался.
Rebase и merge — не одно и то же, и после rebase вам все равно придётся делать merge. Так что сама постановка вопроса является некорректной.
Добавлю, что в случае rebase, конфликтов приходится устранять больше, так как это по сути последовательность cherry-pick-ов, где конфликт может быть на каждом шаге. Тогда как в случае merge — мы устраняем только реальные конфликты на единственном коммите. Несколько дней назад я опубликовал статью, где описал метод, как можно упростить конфликты при rebase.
В чём делались картинки для этой статьи? Мне стиль нравится, хотел бы в подобном стиле сделать свои графики

Отвратительный машинный перевод, отсутствие единой терминологии об одном предмете речи : ветка/вилка, rebase/перемещение

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории