Что правильнее: git merge master VS git rebase?

Question

[hippocrates_ho_koios]

Какой подход правильнее использовать при решении конфликтов слияния: мерджить master в feature или перебазирование feature?

Answer 1

[Антон Иванов]

Ребейз для более чистой структуры ветвления, мерж создаёт дополнительные мерж комнаты. Если работаете один или малым числом разработчиков можно ребейзить. Вообще тема холиварная, почти как винда вс линукс. Попробуйте оба подхода и определите сами для себя, что именно вам подходит.

Answer 2

[Vitsliputsli]

Правильнее merge.
Merge создаст новый коммит в котором объединит 2 ветки.
Rebase удалит все ваши коммиты из ветки, перенесет ветку в другое место и создаст новые коммиты с новым родителем.

Т.е. если чтото не так смержили при ребейзе выковыривать придется из удаленных. Плюсом ребейза считается более "красивая" картинка, по-факту это просто уничтожение истории, а сам факт уничтожения истории в системе контроля версий порождает вопрос, а зачем тогда вообще контроль версий?
Поэтому ребейз не применим, если вы не один пользуетесь веткой. А если один, то все на вашей совести. На практике, конечно не всегда все так катастрофично, поэтому есть предпочитающие ребейз. Специально ради таких вредителей основные ветки проекта делают защищенными от переписывания.
Есть редкие ситуации, когда ребейз предпочтительней, например вы мержите в ветку, но забыли сделать пулл, смысла этот смерженный коммит держать в параллельной ветке нет, лучше при таком мерже выбрать ребейз, т.к. такое переписывание истории будет только локальным.

Comments

[Сергей Кузнецов]

а сам факт уничтожения истории в системе контроля версий порождает вопрос, а зачем тогда вообще контроль версий?

Чтобы управлять историей, а не хранить её в виде археологических слоёв.
Rebase не «уничтожает» историю, а переписывает её так, чтобы она оставалась линейной и читаемой.
Git — не архив, а инструмент. И да, rebase — часть нормального рабочего процесса, если понимать, когда и зачем его применять.

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

Старые коммиты никуда не удаляются. Если что-то пошло не так, ветка возвращается в предыдущее состояние одной командой. Не надо тут вводить в заблуждение )))

ребейз не применим, если вы не один пользуетесь веткой. А если один, то всё на вашей совести

Как раз наоборот: когда вы работаете с веткой один и ленитесь причесать историю через интерактивный rebase перед отправкой в вышестоящий репозиторий — вот тогда это действительно остаётся на вашей совести. ))

[Vitsliputsli]

Сергей Кузнецов,

Чтобы управлять историей, а не хранить её в виде археологических слоёв.
Rebase не «уничтожает» историю, а переписывает её так, чтобы она оставалась линейной и читаемой.
Git — не архив, а инструмент. И да, rebase — часть нормального рабочего процесса, если понимать, когда и зачем его применять.

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

Старые коммиты никуда не удаляются. Если что-то пошло не так, ветка возвращается в предыдущее состояние одной командой. Не надо тут вводить в заблуждение )))

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

Как раз наоборот: когда вы работаете с веткой один и ленитесь причесать историю через интерактивный rebase перед отправкой в вышестоящий репозиторий — вот тогда это действительно остаётся на вашей совести. ))

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

[Сергей Кузнецов]

Созданные коммиты уничтожаются и записываются новые.

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

Если вы всегда "на стреме" и записываете хеш аварийного коммита

Зачем мне быть на стрёме? Гит никогда ничего не удаляет и все ходы записаны в журнале. Легким движением руки можно легко откатиться на момент до неудачного слияния и rebase.

За исключением ситуации, когда прошло время и неиспользуемые коммиты git уже вычистил

Мне трудно представить такую ситуацию, что через месяц захочется покопаться в мусоре и снова пересобрать старые косяки. Обычно проблемы видны сразу.

все это, запрещают делать в важных ветках, где нужен контроль версий.

Контроль версий происходит во всех ветках. А важные мы защищаем от удаления.
Так как rebase это именно удаление и пересоздания на новом месте. Если это делать с общей веткой, то придется всех коллег заставлять тоже удалить у себя эту ветку и создать на новом месте, куда она перекинется. Никто не будет этим страдать и поэтому защищают ветки.

[Vitsliputsli]

Сергей Кузнецов,

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

Ну к чему это жонглирование словами? Сами же дальше пишете "удаление", а тут какаято "витрина". Когда работаешь с версиями, опираешься на конкретный тег или ветку, а не просматриваешь каждый раз мусорку в поисках удаленых коммитов, надеясь что их еще не почистили.
Еще раз, когда вы сделали коммит, вы зафиксировали определенный код. Но, когда вы сделали ребейз и поменяли базу, этого коммита уже нет в ветке, а есть совершенно другой коммит, с другим кодом, который вы почему-то предлагаете считать тем же самым.
А если я повешу тег, и потом сделаю ребейз, что будет с "красивой" картинкой? Правильно будет полная хрень, и старая ветка с реальными коммитами, и новая с "причесанными".
Повторюсь, ребейз это про "красивую" картинку, с коммитами никакого отношения не имеющими к реально сделанным коммитам.

Зачем мне быть на стрёме? Гит никогда ничего не удаляет и все ходы записаны в журнале. Легким движением руки можно легко откатиться на момент до неудачного слияния и rebase.

Сразу не удаляет, это всем понятно и уже сверху упомянуто.

Мне трудно представить такую ситуацию, что через месяц захочется покопаться в мусоре и снова пересобрать старые косяки. Обычно проблемы видны сразу.

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

Контроль версий происходит во всех ветках. А важные мы защищаем от удаления.
Так как rebase это именно удаление и пересоздания на новом месте. Если это делать с общей веткой, то придется всех коллег заставлять тоже удалить у себя эту ветку и создать на новом месте, куда она перекинется. Никто не будет этим страдать и поэтому защищают ветки.

Я выше описал основную проблему, то что комуто придется сделать доп действия это еще полбеды.

[Сергей Кузнецов]

Сами же дальше пишете "удаление", а тут какая-то "витрина".

Вы путаете хранилище и указатель. Ветка в Git — не сейф, а стрелка на коммит. При rebase вы двигаете стрелку, а не трогаете объекты. Коммиты остаются в базе — те же SHA-1, те же данные.

«Витрина» — это метафора для текущей истории ветки. Если вам нужен «архив всех опечаток» — Git его хранит. Но показывать его в основной истории — всё равно что выставлять в музее черновики с зачёркнутыми словами вместо финальной рукописи.

Повторюсь, ребейз это про "красивую" картинку

Если для вас история проекта — «картинка», то вы явно не пишете код, а коллекционируете артефакты. Для разработчиков rebase — не косметика, а хирургия:

• убирает шум (промежуточные фиксы, неудачные эксперименты);
  
• сохраняет логику (каждый коммит — осмысленный шаг);
  
• упрощает ревью (линейная история читается как книга, а не как лабиринт).
  

когда вы сделали ребейз и поменяли базу, этого коммита уже нет

Потому что ветка — ярлык, а не склад. Коммиты никуда не деваются: reflog и object database всё помнят.

Если вам так дороги все промежуточные состояния — вешайте на них теги. Git не запрещает коллекционировать «исторические раритеты». Но требовать, чтобы основная ветка была складом черновиков, — это не контроль версий, а страх отпустить прошлое.

Git — это инструмент для управления историей, а не для её мумификации. Если вам нужно, чтобы каждый коммит был «неприкасаемым артефактом», — да, Git вам не подходит.

Но тогда, может, вам стоит перейти на Mercurial? Он как раз для тех, кто боится переставлять стрелки и верит, что «история должна оставаться такой, какой её написали в первый раз». Git управляет историей. Mercurial её хранит. Поэтому одни делают релизы, а другие пишут манифесты о «неприкасаемости коммитов».

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

[Vitsliputsli]

Сергей Кузнецов, красиво, эмоционально, особенно понравилась попытка вызвать неприязнь к моему мнению через стигматизацию метафорой мумификации. Но технический спор требует технической аргументации, а не ораторских ухищрений.
Контроль версий это бекап, и когда мы его делаем, то ожидаем, что восстановленное состояние будет тем же, какое сохранялось, не на 99%, а на все 100%. Так что это ближе к мумификации, чем к "я художник я так вижу". И когда мы пишем код, мы "коллеционируем артефакты", собранный код так и называем - артефакт. И код, который хранится в git "неприкасаем", если у вас не так, значит у вас нет контроля версий.
Еще раз, в основных ветках, там где нужен контроль версий, ребейз запрещают (вернее любое переписывание истории), и вы это знаете, так зачем пытаетесь ввести в заблуждение?
В личных ветках, в ветках фич и т.п. могут отходить от этого правила, там действительно могут жертвовать контролем версий для "красивой" картинки, без черновиков и т.п. И тут, как уже писал, все на вашей совести. Хотите делаете, не хотите - не делаете, особенно если работаете один. Но, нужно понимать, что вы можете "убрать шум", сделать "каждый коммит - осмысленный шаг" и т.п. (ревью делают обычно для пулреков, так что там от переписывания истории только хуже), но это не контроль версий, т.к. у вас при каждом новом ребейзе появляются все новые и новые версии, даже старых "осмысленных шагов". Так что вы правы, "не косметика, а хирургия", вы отрезали человеку руку, пришили руку от другого - и говорите, "а че, ну похоже же на то что было", только вот похожесть это не про контроль версий.
Ваша "полезность истории" в меньшем кол-ве полосочек в графическом представлении связей. Но, чем она полезна на самом деле? А ничем, она бесполезна, потому что, как вы писали:
"Мне трудно представить такую ситуацию, что через месяц захочется покопаться в мусоре и снова пересобрать старые косяки. Обычно проблемы видны сразу."
Вы сознательно отказались от контроля версий, прямо об этом пишете, но при этом пытаетесь ввести в заблуждение демагогией, а не фактами.
- Можно вернуться к версии, которую мы видели месяц назад?
- Нет, но есть похожая версия, почти такая же (на 90% или может на 10%), зато на "картинке" она выглядит лучше. nuff said
Так что продолжайте "делать релизы, а другие пишут...", никто ж видно кроме вас их не делает, вы один тут такой молодец... Только причем здесь релизы и контроль версий? Хватит демагогии, пожалуйста.
Отказались и отказались, но не нужно убеждать никого, что контроль версий есть там, где его нет.

Answer 3

[Dmitry Roo]

Лучше мердж.
С ребейсом будут проблемы, если ветку использует кто-то еще.

Answer 4

[Сергей Кузнецов]

Вопрос поставлен некорректно — merge и rebase не используются для решения конфликтов — наоборот, именно при их выполнении конфликты и появляются.

Разница лишь в том, что при merge вы решаете конфликты один раз — при создании коммита слияния.
А при rebase Git воспроизводит историю коммитов заново, и вам, возможно, придётся разруливать конфликты на каждом из них.

Нет правильного или неправильного способа слияния. Используйте тот, что уместен в контексте.
Если ветка короткая и никто кроме вас с ней не работает, можно аккуратно пересобрать её через rebase — история будет выглядеть чище, будто вы только что ответвились от актуальной версии проекта.