Comments 17
поэтому убедитесь в том, что делаете!
Ммм, что это означает?
А вот мердж в мастер уже скорее стоить делать именно merge'ем, во всяком случае если вы не гуру гита.
Я не то, чтобы адепт, но плюсы есть:
- Стимулирует делать в одной ветке одну задачу.
- При следовании спеке 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.
В целом, rebase существенно более мощный и многофункциональный инструмент, чем просто merge. Но обратной стороной является то, что им так же легко репозиторий привести к испорченному состоянию.
Что было бы полезно — сделать какую-то основательную статью с анализом всех популярных подходов к git flow и их подводных камней. В частности, в реалиях наличия ci/cd (когда мы хотим недоделанный код катить и сразу видеть результат его выполнения, кстати, ребейз в этом случае чреват ещё дополнительными рассинхронами с теми же средствами сборки и хранения артефактов)
За перевод спасибо, каких-то сильных ляпов в нем не нашел, но особо и не вчитывался.
Введение в Git Merge и Git Rebase: зачем и когда их использовать