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

На всех собесах, где спрашивали Git, обязательно спрашивали этот вопрос (в теме видео). Спасибо за доходчивое объяснение!

Спасибо! Всегда делал мердж, но после просмотра видео понял, что можно и рибэйз использовать)

Очень красивое видео, прям как елочка. Спасибо за видео

Все чаще возвращаюсь на этот канал для заполнения пробелов в своих знаниях.

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

Оочень четкое и понятное объяснение! Большое Вам спасибо!

посмотрел 5 видео по этой теме, только на вашем понял. спасибо, подписался

Огромное спасибо за видео. Наконец-то получилось найти простое и доступное объяснение про эти команды.

Наконец-то)) спасибо вам, очень хорошо объяснили, я до этого читала. И никак не могла понять. У меня скопилось много разных версий. Так и жила несколько лет 😀. Документацию к гиту писал какой - то душнила, чтоб было максимально непонятно и запутанно.

Классно объясняете, понятно. Спасибо большое!

Спасибо за видео! Отличное объяснение отличий, плюсов и минусов обоих методов.

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

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

Спасибо большое за объяснение. Первый раз на вашем канале и сразу же подписалась. Доходчивое объяснение со схемами. И отдельный респект за вставки различных мемов, гифок и "красивометр" 😁. Это помогает взбодриться и смотреть видео с бОльшей концентрацией.

Работаем по разному, но в основном через merge из-за надежности. Когда бывает очень много малозначимых коммитов , например исправление опечаток в словах, тогда обычно мы делаем squash или интерактивный rebase, но видимо это следующее видео в цикле Git :) PS: спасибо за труды, новичков в команде часто приходится подтягивать поэтому советую что посмотреть и с какого канала, у вас достойные и наглядные объяснения - буду советовать.

Лучшее объяснение. Спасибо огромное!

Супер! Очень доходчиво! Отдельное спасибо за вставки картинок и гифок! Поржал))))

Супер!!! Самое лучшее объяснение, все просто и ясно, спасибо)))

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

Чел, отличное видео! Благодаря ему я всё же понял, когда и что использовать. Большинство говорит, что эти команды делают, но когда их использовать чётко - мало кто)

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

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

Спасибо, отличное наглядное объяснение!

Знал, что rebase этот мерж только по-другому, но как именно по другому не понимал (описания до этого читал перемудреные). После этого видео все стало понятно, спасибо!

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

Лучшее объяснение! 👍

Спасибо большое! Мега-понятно !

Спасибо, дошло!

Вот теперь всё понятно, спасибо!

Крутое видео и канал ооочень интересный, я очень надеюсь, что не забросишь, а будешь только дальше развиваться, спасибо!

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

Нраицца. Спасибо. Использую merge постоянно. Теперь готов попробовать rebase

Объяснение merge и rebase на котиках это же гениально!))

Дай тебе Бог здоровья, хлопчик, наконец-то дошло до старика.

Самое доходчивое объяснение ! спасибо!

Полезно) спасибо за видео вам

Отличный видос, без воды по полочкам, спасибо

Лайк. Чистый вопрос на собеседовании. Плюс хорошее объяснение для понимания. Спасибо большое. Подписка.

Спасибо, очень доходчиво и на котиках. Успехов!

Класс, благодарю, супер понятно!

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

Спасибо большое за крутой контент. Очень информативно и понятно

Да. Спасибо Сергей. Всегда хватало merge, но не давно начал искать работу и не знал даже что существует такая команда как rebase. Я просто и сказал так что не знаю - в результате не прошёл, но поинтересовался. Греет душу что не упал всё таки лицом в грязь, так как это фактически аналоги.

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

Cпасибо, мне как начинающему разработчику было очень полезно!

Очень хорошее видео, спасибо!

Спасибо. 4:23 rebase (состав + состав) Одному разрабу на ветке самый раз. Многим разрабам нужно осторожно так как меняется история и hash коммитов.

спасибо мен, очень подробно объяснил!)

Здарово Серег. Спасибб

О круто. Не использовал даже. Спасибо

Спасибо за контент!

👍👍👍 вообще огонь!

Доходчиво. Спасибо.

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

Наконец-то я понял что за rebase. Спасибо!

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

Спасибо! Все понятно!

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

братан не знаю как но ты самый понятнее всего обьяснил из всего простора инета

Нормальное объяснение ребейса, Наконец-то!

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

Сопроводительные вставки повеселили, и я даже походу понял как это работает)

💯✨💯✨Идеально объяснил

Гениально!

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

Всё-таки можно посмотреть в какие моменты "подобновляли" свою ветку. Нужно ребейз делать с флагом --committer-date-is-author-date Но это и не важно (дата обновления). Важна лишь последовательность и дата, когда данный коммит попал в общую ветку, т.е. повлиял на других.

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

спасибо!

Спасибо огромное)

пользуюсь только merge, как раз потому что не имел ни одного проекта, который разрабатывал бы один отличный материал, спасибо!

о, спасибо теперь понятно что и когда

Спасибо!

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

спасибо за понятное объяснение. подписался на канал

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

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

Достойно лайка

Great!

Крутяк!!!!

шикарно

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

Спс, за обьяснения. Я всегда боялся ребейза. Я толком даже и мердж не юзал - всегда писал git pull origin branch...Спс за обьяснение

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

Наконец то я стал понимать о чем речь!

Использовали и мерж и ребейз. Ребейз более опасная операция по сравнению с мержем, решили, что кто как хочет, тот так и делает в своей ветке. В сумме, не сильно мешает потом найти коммит с изменениями.

спасибо, классно объяснили #git #merge #rebase

top, super, like

Полезно

используем ребейз прямо в мастер, не о чем не договариваемся с коллегами, даже если работаем вдвоем-троем-четвером над одной фичей в одних и тех же файлах, но бывает так, что синкаемся при конфликтах, но в целом все ОК)

спасибо

Я использую такую синюю стрелочку, указывающую в левый нижний угол, в PhpStorm. Я хз, что именно она делает, но я получаю все последние обновления в ветке))

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

У нас на проекте аналогичный подход )

Агонь! Где ты был раньше?

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

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

Я новичок и как раз задался этим вопросом. Ваш ответ очень доходчив, спасибо. Подписался. Я работал один в своей ветке, несколько раз уже делал рибэйз (git checkout dev / git pull / git checkout feature, / git rebase dev), но, с каждым новым таким рибэйзом мне прилетает все больше кофликтов, где надо вручную их разрешать, хотя мои коммиты не затрагивают файлы основной ветки dev. Техлид просто посоветовал делать merge и не использовать rebase.

17 лет в разработке. Норм ман для начинающих!

Эх, раньше бы знал, спасло бы несколько раз от разгребания бардака)