Comments 21
поэтому убедитесь в том, что делаете!
Ммм, что это означает?
А вот мердж в мастер уже скорее стоить делать именно merge'ем, во всяком случае если вы не гуру гита.
Я не то, чтобы адепт, но плюсы есть:
- Стимулирует делать в одной ветке одну задачу.
- При следовании спеке Conventional Commits получаем чистые и полезные описания всех коммитов в master, при этом над описаниями коммитов в фиче-бранчах можно не париться (ибо зачастую их в принципе невозможно контролировать, напр. когда получаешь сторонний пул-реквест на гитхабе).
- Упрощает revert при проблемах.
- Упрощает bisect.
А вот явных минусов особо не видно. Да, теряется пошаговая история как кто-то пилил фичу и лажал в процессе — ценность этой истории после мержа фичи обычно нулевая. Если будет очень надо — в течении месяца её можно будет ручками восстановить из reflog.
Про последнюю реплику, из практики - ценность смерженной фичи нулевая, если она "идеальна". Но если там нет ни одной баги. А по факту, когда есть баги (а это всегда так!) есть баги явные либо (практически всегда!) неявные (вроде мемликов) - ценность очень велика! Пол-дюжины "git bisect" очень живо натренируют и направят мозг в нужную сторону! То, как кто-то "пилит фичу и лажал в процессе" - гораздо ценнее, чем полное отсутствие контекста + коммит/патч на 10к+ строк. При этом reflog - он локален, только у "пилильщика". И, очень возможно, давно удалён GC.
Не уверен, что понял где тут ценность. Начиная с того, что выявленный после мержа фичи баг может находится в месте, которое в процессе работы над этой веткой многократно менялось и рефакторилось (т.е. ценность всей истории изменения даже конкретно той точки где в финале оказался баг очень сомнительна) и заканчивая тем, что даже это может являться ценностью (пусть даже и сомнительной) исключительно для автора этой ветки (т.е. того, кому доступен 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 (когда мы хотим недоделанный код катить и сразу видеть результат его выполнения, кстати, ребейз в этом случае чреват ещё дополнительными рассинхронами с теми же средствами сборки и хранения артефактов)
За перевод спасибо, каких-то сильных ляпов в нем не нашел, но особо и не вчитывался.
Отвратительный машинный перевод, отсутствие единой терминологии об одном предмете речи : ветка/вилка, rebase/перемещение
Введение в Git Merge и Git Rebase: зачем и когда их использовать