GIT: Merge или Rebase? В чем разница?

мужик, спасибо!

Добрый вечер! По моему, не было сказано, что при команде "git rebase master" (т.е. при вставке текущей feature-ветки в конец master-ветки), коммиты feature-ветки не будут видны в master-ветке (т.е. они как бы останутся изолированными).
И чтобы их объединить надо выполнить команду (из master-ветки): "git merge feature".

Единственная причина, по которой историю слияний трудно понять, — это плохое графическое представление истории и ветвей. Работать с git на консолях, когда есть графические инструменты — это мазохизм. Об этом я даже говорить нестану.
Но в графических представлениях самая большая проблема заключается в том, что изображение не соответствует действительности. Самая большая проблема заключается в том, что никто (из тех, кого я видел) обычно не указывает, какая ветка какая.
Например. 5 веток. Один входит в один. Другой выходит из другого. А как называется какая ветка, в лучшем случае можно посмотреть места подключения. В лучшем. Но если ветки выходят за пределы видимой области, то при наезде на ветку обычное наведение ничего не показывает. Не то, что это за ветка, не то, что такое последний коммит. Мастер начинает двигаться где-то посередине веток только потому, что последний мастер-коммит находится не весь в мастер-ветке, а в какой-то feature ветке. Кошмар.
Если есть hotfix, поместите их в крайнее левое положение и разделите их. Рядом справа находится ветка master. И не важно, где последний раз был сделан коммит. Мастер следующий. Затем идет ветка develop. За master. Снова - Не имеет значения, кто сделал последний коммит. Порядок веток не изменился. А затем вправо разветвляются функции в порядке их появления. А что касается "title", независимо от того, в какую ветку вы заходите, "title" показывает название ветки, текст последнего коммита, дату и «автора». Все. Тогда не будет проблем с пониманием истории. Хаши? Можно показать где-нибудь ниже. Но кто сможет запомнить хэши в долгосрочной перспективе, чтобы проследить историю через них. Кошмар.
GitKraken, PhpStorm и несколько других страдают от этава кошмара.
Если вы знаете app, которая нормально отображать подобное, поделитесь, пожалуйста, в комментариях.
Я повторюсь. Консоль не интересует. Я не мазохист. Я выучил команды. Поигралса 5 минут. Достаточно. Есть графические отображение. Вродье.

Кто нибудь смотрит граф комитов? Если да то зачем?

Спасибо, очень понятно, топ!

лайк, подписался

Крутой материал!

Спасибо, полезно

спасибо за объяснение

Отличное разъяснение, спасибо!

Так-то все по делу, но звук - какофония какая-то. Хочется через две минуты просто зажать уши. Ну сами послушайте...

Great!

Использую всегда merge, в проектах несколько разрабов, поэтому безопасность превыше эстетики)

Ничего не изменилось) Этот же вопрос спрашивают на собесах DevOps.

Оказывается, я любитель метро (((

шикарно

Git pull master тоже делает merge?

А где взять такой конспект с котиками?

А ещё можно делать rebase при мерже мастера в фичу. Но потом при мерже фичи в мастер делать merge --no-ff. Получится и граф приличный и возможность простого выкашивания фичи из мастера, если с ней что-то не то, - останется.

Проблему метро Токио решает `git merge --squash`

pidor

крутое объяснение, спасибо!

Благодарю тебя добрый человек!

sub, nice

top, super, like

Like

Правила просты - соблюдайте их и будет вам ЩАСТЕ:
- НИКТО и НИКОГДА не пихает коммиты (push) в чужие ветки - делайте СВОЙ бранч и работайте там спокойно (напомню, что её даже пушить - не обязательно если работаете один).
- В СВОЮ ветку для получения изменений извне лучше делать Rebase, в любую чужую - не важно чью, не говоря уже про базовые master/develop - только Merge - иначе вам придут и сломают лицо.

Из этого следует: когда над фичей работают несколько разработчиков - делается отдельная feature-ветка, после чего каждый из них ОБЯЗАН сделать СВОЁ собственное ответвление от этой feature-ветки (Branch) и продолжать работать по стандартным правилам, договариваясь отправляя сообщения: "я сегодня сделаю merge в основную feature ветку - есть возражения?" И после успешного MERGE - второе: "Ребята, я сделал merge в feature ветку - обновитесь".

rebase

Отличное видео!
Но слушать невозможно из-за этих видео-вставочек, просто ржу ))) Приходится все время останавливать видео )

при колективній роботі на одній гілці можна ж користуватися методом git fetch + git rebase потім git push

Спасибо, за доступное объяснение!

Отлично объяснил, спасибо Сергii 👍

Спасибо, очень понятно)

Как же доступно автор всё объяснил! Спасибо!

Все понятно, спасибо

Благодаря этому видео, вопрос по мерджу/ребейзу для себя закрыл. Очень доходчиво объяснил. Дякую!;)

Супер объяснение! а можно такое же объяснение для - git squash?

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

А если я несколько раз буду обновлять свою фича ветку разными (обновленными) мастерами, то эти мастера в конфликт не войдут между собой? и не будут ли каждый раз заново добавляться к моей фича вет
ке? не окажется ли перед моей фичой после нескольких обнновлений 5-6 мастеров разных версий?

Отличное объяснение, спасибо!

фичуретка

Я могу только один лайк постовить)) Сорри))

красивометр заставил меня ухмельнуться😄

Круто! А можно ребейз откатить? Если при ребейзе неправильно решены конфликты

великолепное объяснение и прекрасная подача материала! спасибо!

На собесах для мидлов задают такие вопросы.
Огромное спасибо автору за простое и полное объяснение!

респект, красавчик

Гениально!