Введение в Git Merge и Git Rebase: зачем и когда их использовать

[Neusser]

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

Ммм, что это означает?

[NorthDakota]

Rebase — это то что нельзя делать.

[worldmind]

Статья ни о чём — rebase (интерактивный) можно и нужно использовать для наведения порядка (собрать коммиты в осмысленные и законченные коммиты) в своей ветке перед мерджем как бы он ни выполнялся, также rebase разумно использовать для синхронизации своего форка/ветки с главной веткой чтобы не иметь мусора про мерджи в истории.
А вот мердж в мастер уже скорее стоить делать именно merge'ем, во всяком случае если вы не гуру гита.

[ilammy]

Из-за стремительного уменьшения относительной доли гуру гита среди пользователей гита уже давно набирает популярность squash merge, когда в master ваша ветка всегда попадает в виде одного коммита.

[horror_x]

А чем адепты squash merge аргументируют свой подход? Типа раз никто не следит за своей историей коммитов, то вместо наведения порядка тупо «округлим» её до коммита на фичу?

[Dreyk]

некоторые contribution считают под количеству коммитов, поэтому 1 фича — 1 коммит. что в целом не так-то уж и плохо

[powerman]

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

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

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

[ilammy]

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

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

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

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

[worldmind]

Это отличный способ если мерджатся изменения которые имеет смысл иметь в виде одного коммита.

[dbagaev]

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

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

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

[maxim_ge]

Да, это описание гораздо лучше, чем то, что в статье.

[sshikov]

Это все уже было, причем много раз, во вполне нормальном виде.

[house2008]

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

[gecube]

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

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

За перевод спасибо, каких-то сильных ляпов в нем не нашел, но особо и не вчитывался.

[gdt]

Rebase и merge — не одно и то же, и после rebase вам все равно придётся делать merge. Так что сама постановка вопроса является некорректной.

[capslocky]

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

[nZeus]

В чём делались картинки для этой статьи? Мне стиль нравится, хотел бы в подобном стиле сделать свои графики

[GrimAnEye]

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