GIT: Merge or Rebase? What's the difference?

[@kisurov]

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

[@frontendscience]

Ухты класс! Не знал что такое на собеседованиях спрашивают. Рад что было полезно!

[@рострост-м6з]

Собесы на джуна?

[@kisurov]

@@рострост-м6з И на джуна и на мидла. Я их много проходил. Некоторые компании (например Luxoft, Epam) сначала проводят жёсткий собес, а потом на его основании определяют твой уровень.

[@denisoleksyuk5346]

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

[@anastasiyaboiko8862]

У меня это спросили в епаме на собесе для лабы. Я помнила только что ребейз плохо, а мерж хорошо :D

[@vasilyh4588]

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

[@basvalan]

У вас там что-то о пул реквестах слышали?

[@vasilyh4588]

@@basvalan Наличие процесса pull requests - зависит от договорённостей и метода разделения ответственности в команде. Ну и от настроек, которые, иногда, некому делать.

[@MrNightingale1989]

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

[@frontendscience]

Рад что было полезно!

[@MrNightingale1989]

@@frontendscience в прошлом видео видел, что ты используешь элиас lg для вывода гит лога. Какие ещё используешь? Я кроме lg ещё last добавил себе для вывода последнего коммита. Спасибо!

[@petroboiko3019]

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

[@frontendscience]

Рад слышать:) успехов Вам!

[@inaccessibleJr]

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

[@frontendscience]

Старалси :)

[@atlantatesla9348]

Мне тоже понравился момент с елочкой 👍

[@desire88]

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

[@gerasim_vol]

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

[@frontendscience]

Очень вдохновляет! Спасибо за обратную связь! Будем еще больше стараться)

[@Vlad-em1bx]

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

[@WalkHB2]

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

[@ТимурТокумов-и1к]

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

[@slaviksemen4919]

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

[@andygr1n1]

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

[@ИльдарГареев-в9ч]

рассказ про ветки же

[@andreypr503]

одна ветка на проект?

[@peacedets]

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

[@MrKoTera]

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

[@frontendscience]

Рад, что пригодилось, бро)

[@dreamer_vi905]

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

[@Rom4eS]

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

[@RinMagnetic]

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

[@frontendscience]

И Вам спасибо! )

[@КсенияСидельникова-о3г]

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

[@andyanderson222]

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

[@dmytrokireiev9241]

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

[@frontendscience]

Класс! Спасибо)

[@bama2619]

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

[@ross-c3h]

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

[@ЦветыЗла-х1ш]

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

[@frontendscience]

Очень рад. Благодарю, что написали.

[@artkoorosawa6432]

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

[@andreifokin311]

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

[@frontendscience]

Прикольно! Рад, что понравилось! Я старался))

[@Евгений-и3о3е]

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

[@frontendscience]

Рад, что оказалось полезно)

[@atlantatesla9348]

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

[@Polinko007]

мне тоже зашли мемы, гифки и красивометр 😁 хотя когда появился красивометр, я наоборот немного потеряла концентрацию, по большей части от забавности ситуации 😆

[@margino]

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

[@eaglesm1993]

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

[@filinyellow7134]

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

[@frontendscience]

И Вам спасибо, что смотрите! Рады стараться.

[@avorion-ru]

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

[@МихаилБелошкурский]

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

[@frontendscience]

И Вам спасибо)

[@mzx6531]

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

[@frontendscience]

Рад, что было полезно

[@pesilwoof]

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

[@SergeiCherkesov]

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

[@frontendscience]

Класс! Рад, что помогло!

[@ТимофейЁлкин-о9е]

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

[@АртемАрте-г5х]

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

[@tanyaDreamer]

Самое ёмкое и понятное объяснение😍 Спасибо!

[@tangor268]

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

[@SEYANARACORE]

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

[@frontendscience]

Благодарю за поддержку! Рад, что оказалось полезно)

[@docshark11]

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

[@bohdan2812]

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

[@DmitryYaskov]

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

[@dmitry6687]

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

[@frontendscience]

Рад, что оказалось полезно!

[@МаксимСімончук]

Невероятно, Сергей, я думал вы из России, помню видео где вы над проектом ВКонтакте работали, а сейчас узнал, что вы из Украины, очень здорово, что такой крутой человек поддерживает Украину❤ удачи вам в будущем

[@КириллПривалов-я7з]

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

[@Andrew-strong]

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

[@frontendscience]

ОООО..... это очень холиварный вопрос. Тут очень много зависит от самого проекта и еще от частоты обновления, важности синхронизации бакенда и фронтенда и др. Я лично за более микросервисную архитектуру и разделение ответсвенности. Но есть много проектов где такой подход не пройдет. Так что - как говорят it depends. PS: на последок рекомендую для общего развития поискать в интернете информацию про monorepo подход. Самый крупный монорепо в Мире например у Гугла - весь код всего лежит в одном репозитории.

[@АртемАрте-г5х]

1 проект - 1 репозиторий. Фронт это один проект. апи сервера это другие проектЫ. Т.е. репозиториев должно быть ни менее 2. Два апи+фронт = 3 репозитория.

[@АртемАрте-г5х]

@@olezhonnv3215 до поры до времени, пока 10 человек с разными целями не попытаются это всё смержить и куча конфликтов либо кривой автомрж всё не похерит. Уже проходили.

[@MrEugen25]

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

[@frontendscience]

Рад что оказалось полезным!

[@Shakl-e]

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

[@ingvarr6235]

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

[@frontendscience]

Рад, что было полезно! Спасибо за поддержку

[@zl0n1k]

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

[@Dmitriy-bq2xh]

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

[@yaroslavzef7267]

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

[@ВладПашковский-ц2э]

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

[@Alexander_Ezhov]

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

[@maksym.kondratenko]

Гениально!

[@frontendscience]

Благодарю! 👍

[@1mujer98amante5]

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

[@shelovessugar9950]

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

[@arturmusin1958]

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

[@frontendscience]

Рад, что оказалось полезно! Спасибо, что смотрите)

[@suspiciousgoose7904]

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

[@K-BotN_]

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

[@frontendscience]

И Вам спасибо ;)

[@alexeypashchenko]

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

[@frontendscience]

Рад, что было полезно)

[@FootballRS7]

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

[@dzen1234]

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

[@a.osethkin55]

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

[@thghtfl]

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

[@diadia6218]

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

[@АлександрКиселев-е2г]

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

[@frontendscience]

И Вам спасибо! ) Рад, что пригодилось

[@ssurrokk]

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

[@HIghtowerSever]

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

[@frontendscience]

Могу посоветовать один метод который поможет или вообще избавиться от конфликтов или их прийдется решить один раз. Перед тем как делать ребейз нужно сосквашть (склеить) все комиты в фичеветке.

[@frontendscience]

Про то как склеить комиты расскажу в следующем видео

[@HIghtowerSever]

@@frontendscience ну давай до конца уж. Как команда выглядит?

[@HIghtowerSever]

@@frontendscience Интриган :)))

[@frontendscience]

interactive rebase

[@razmus89dragovich20]

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

[@frontendscience]

Супер! Очень рад!

[@amir18n]

спасибо!

[@dmitriy9152]

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

[@viktorzherekhin8590]

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

[@Das.Kleine.Krokodil]

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

[@UserName32048]

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

[@UralSmart]

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

[@vladvoloshenko5701]

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

[@skynowa2626]

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

[@frontendscience]

Рад, что понравилось! Благодарю за поддержку)

[@SergeiKjtydghk]

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

[@kirill_prog]

А чтобы подобновить свою ветку, нужно ведь master подтянуть сначала git pull?

[@SlavaCh]

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

[@eakzit3181]

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

[@frontendscience]

Класс! Рад, что оказалось полезным!

[@kenanhaciyev3759]

шикарно

[@Nightship]

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

[@temik26]

Если я правильно понял, то итог таков: если я один на веткой работаю, то лучше через rebase брать обновления с master, а если несколько человек работают в одной веткой, то merge.

[@frontendscience]

Да, все верно.

[@temik26]

@@frontendscience Благодарю Вас за видео!

[@frontendscience]

@@temik26 И Вам спасибо за просмотр!

[@ВасилийБарков-к2э]

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

[@frontendscience]

Рад слышать 👍

[@MrVitalirapalis]

only git merge, i am lame duck :) nice video bro

[@frontendscience]

Thanks! 👍

[@dmitry9894]

7:15 - застешил локальные изменения потом спулил из ветки ребезнутую другим девом версию и поверх анстешнул ну или на худой конец можно черипикнуть, не вижу проблем

[@frontendscience]

1. Застешить не выйдет. Из примера в видео я сказал что уже коммиты в своей ветке есть. 2. В видео я привел решение - делать пул с ребейзом всегда: git pull --rebase origin feature 3. Для того чтобы это работало надо обязательно внутри команды договориться о flow по которому все без исключения будут работать.

[@konstantinz5058]

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

[@leokorsunsky2395]

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

[@frontendscience]

И Вам спасибо :)

[@ОлегСелин-ш9ы]

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

[@frontendscience]

Та да, все через это проходят)

[@devak88]

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

[@Developer_python_]

Great!

[@xoxo2880808]

Спасибо!

[@ihormanzii]

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

[@frontendscience]

Рад, что оказалось полезно!)

[@zubescu]

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

[@frontendscience]

Рад, что было полезно!

[@vladko9623]

Честно, ни разу не использовал git rebase (даже не знал про такую команду). Только git merge.

[@vital708]

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

[@sanya8158]

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

[@frontendscience]

И Вам! )

[@VitMS1]

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