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

В этом видео мы рассмотрим с вами 2 способа, как перенести git коммиты из одной ветки в другую. В этом нам помогут команды Merge и Rebase.
В чем их отличия, какие сильные и слабые стороны у каждой из них. И чем пользоваться на вашем проекте? Про все это смотрите в нашем видео!
А вы мержите или ребейзите? Напишите нам внизу в комментариях!
---
Если видео было для вас полезным, ставьте лайк и поделитесь им с друзьями.
Подписывайтесь на наш канал: bit.ly/fs-ytb
---
Присоединяйтесь к нам в соцсетях:
FB: / frontendscience
Instagram Сергея Пузанкова: / puzankovcom
Заходите на наш сайт: frontend-scienc...
#git #merge #rebase

[@petroboiko3019]

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

[@frontendscience]

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

[@kisurov]

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

[@frontendscience]

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

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

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

[@kisurov]

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

[@denisoleksyuk5346]

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

[@anastasiyaboiko8862]

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

[@gerasim_vol]

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

[@frontendscience]

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

[@Vlad-em1bx]

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

[@MrKoTera]

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

[@frontendscience]

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

[@RinMagnetic]

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

[@frontendscience]

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

[@Rom4eS]

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

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

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

[@filinyellow7134]

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

[@frontendscience]

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

[@WalkHB2]

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

[@bama2619]

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

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

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

[@frontendscience]

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

[@atlantatesla9348]

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

[@Polinko007]

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

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

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

[@tanyaDreamer]

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

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

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

[@Andrew-strong]

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

[@astrotrain]

У меня проект, и фронт и бэк в одном репозитории, но файлы и папки разные, друг другу вообще не мешаем. Проект на битриксе, но битрикс используем просто как админку, фронт общается с бэком через апи.

[@frontendscience]

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

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

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

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

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

[@artkoorosawa6432]

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

[@eaglesm1993]

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

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

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

[@frontendscience]

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

[@ingvarr6235]

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

[@frontendscience]

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

[@pesilwoof]

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

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

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

[@frontendscience]

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

[@HIghtowerSever]

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

[@frontendscience]

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

[@frontendscience]

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

[@HIghtowerSever]

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

[@HIghtowerSever]

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

[@frontendscience]

interactive rebase

[@SEYANARACORE]

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

[@frontendscience]

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

[@DmitryYaskov]

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

[@mzx6531]

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

[@frontendscience]

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

[@Dmitriy-bq2xh]

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

[@arturmusin1958]

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

[@frontendscience]

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

[@amir18n]

спасибо!

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

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

[@frontendscience]

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

[@RasVivas]

Благодарю за ваши старания! Хотел спросить по другой теме: У меня есть кошелёк OKX с USDT, и у меня есть seed фраза. (behave today finger ski upon boy assault summer exhaust beauty stereo over). Может подскажете, как отправить их на Binance?

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

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

[@frontendscience]

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

[@MrEugen25]

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

[@frontendscience]

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

[@temik26]

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

[@frontendscience]

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

[@temik26]

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

[@frontendscience]

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

[@Alexander_Ezhov]

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

[@dmitry6687]

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

[@frontendscience]

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

[@docshark11]

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

[@diadia6218]

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

[@kirill_prog]

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

[@shelovessugar9950]

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

[@SlavaCh]

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

[@dzen1234]

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

[@thghtfl]

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

[@tangor268]

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

[@dmitriy9152]

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

[@nardo988]

а чем git merge master отличается от git pull origin master ? у нас в компании через pull origin под обновляют ветку

[@frontendscience]

pull стягивает и мержит. А merge - мержит локальную ветку с локальной (без стягивания).

[@viktorzherekhin8590]

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

[@devak88]

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

[@skeelo3157]

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

[@razmus89dragovich20]

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

[@frontendscience]

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

[@skynowa2626]

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

[@frontendscience]

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

[@UralSmart]

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

[@Nightship]

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

[@dmitry9894]

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

[@frontendscience]

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

[@SergeyKardashev]

предлагаю отзеркалить свое изображение (flip horizontal) чтобы соблюдать логику "слева направо" когда показываете первое левой рукой, а второе (следующее) правой рукой

[@zl0n1k]

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

[@SergeiKjtydghk]

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

[@ZXCk5kovo]

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

[@leokorsunsky2395]

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

[@frontendscience]

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

[@veraburak8049]

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

[@MrVitalirapalis]

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

[@frontendscience]

Thanks! 👍

[@maksym.kondratenko]

Гениально!

[@frontendscience]

Благодарю! 👍

[@konstantinz5058]

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

[@vital708]

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

[@VitMS1]

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

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

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

[@frontendscience]

Рад слышать 👍

[@mikhailivlev]

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

[@sazonikv5086]

А в чем разница между merge and rebase?

[@Deadragonbone]

Стараюсь рибейз использовать, когда мердж используешь в гитлабе в cd/ci разделе потом этот мердж комит вылазиет, а не твой комит и не информативно выглядит. И еще рибейз удобней для сборки релиза, как раз из-за отсутствия мерджей лишних

[@vitaliymakarov2928]

Подскажите откуда картинка ближе к концу со схемой котами)

[@frontendscience]

Из интернета. Она у меня в архиве очень давно лежит.

[@tarkus2000ua]

girliemac.com/blog/2017/12/26/git-purr/

[@zubescu]

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

[@frontendscience]

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

[@Das.Kleine.Krokodil]

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

[@xoxo2880808]

Спасибо!

[@ЕвгенийМеньшов-д9г]

А откуда взяли картинки объяснения Гита с котиками?

[@frontendscience]

girliemac.com/blog/2017/12/26/git-purr/

[@gatrianL]

Контекст вызова this, простым языком будет видео?

[@frontendscience]

Если есть запрос - да, сделаем :) Спасибо за идею!

[@TheBaragoz]

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

[@sanya8158]

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

[@frontendscience]

И Вам! )

[@Alex_La]

Когда я вижу git checkout feature у меня возникает ассоциация, что эта команда существует для выхода из ветки, а для входа нужна команда git checkin

[@frontendscience]

Наверное многие видели такое, поэтому сделали команду git switch. Она меняет ветку )

[@aliaksandrkisel2359]

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

[@AHToHK]

Спасибо за объснения. А вообще есть возможность, используя merge (а на rebase), сделать pull request (например, на github), содержащий только свои изменения в истории?

[@frontendscience]

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

[@VoimiX2008]

git pull origin master )

[@АндрейГосподин-е4м]

00:46 начало

[@НатальяОлейник-о7у]

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

[@frontendscience]

Если Вы меняете историю и она отличается от той, что на внешнем сервере, то да, только форс пуш. Иначе гит не даст Вам отправить это на внешний сервер. Если Вы разрабатываете локально и делаете ребейз и никуда еще ничего не пушили, то можно и дальше делать коммиты, ребейзы, а потом один раз отправить ветку на удаленный сервер.

[@mak_whisk]

спасибо

[@olegborodko218]

смотрю этот видоз минимум 3й раз, голова моя дырявая .. Это как мультики для детей. Когда-то я все-таки запомню что к чему. Так привык к мержу что наброчь отбивает что еще там можно сделать

[@PhylJoy]

Отсылка на красивометре "142" из "Автостопом по галактике" ?

[@frontendscience]

Можно и так сказать! Тока там было просто 42

[@Bob-fh6jb]

Крутяк!!!!

[@frontendscience]

Рад, что понравилось)

[@vladimirprudnikov]

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

[@hasst9261]

Полезно

[@МаріяКончак-в6з]

Нельзя использовать git pull origin master ? Для обновления

[@frontendscience]

Если сделать git pull origin master, то будет сделан merge commit в ветке со свежими изменениями из мастера. А если сделать git pull --rebase origin master то тогда ветка будет отребейжена от мастера

[@ivanserdiukov5680]

sub, nice

[@Andris_Briedis]

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

[@not2000ful]

Что бы я не смотрел везде не понимают видимо как это работает, мердж не ввиде одного коммита переносит изменения, он переносит все коммиты из другой ветки также к вам в ветку (Ну это из того что я на практике наблюдаю), а шо этот чел в видосе себе напридумывал я хызы

[@MrOverHerz]

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

[@frontendscience]

Именно поэому я говорил что форспуш можно делать только на своей фиче ветке - а не когда в ней работает много людей! Рад, что вы так внимательно посмотрели видео!

[@MrOverHerz]

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

[@nesigaev]

Для меня, как новичка, тема обработки конфликтов осталось не раскрытой. С обычным merge все более-менее понятно (3-х стороннее сравнение, фаст-форвард по-возможности и т.п.), а с rebase? По ролику сложилось впечатление, что конфликты по-боку. Если это так, то почему ни слова об этом? Неужели настолько неважен про8б чьих-то доработок?

[@frontendscience]

Ризолв конфликтов при мерже и рибейзе не отличается. Видео было не про это.

[@ДмитрийЛысов-х1з]

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

[@lightinthedark5708]

также частенько, чтобы забрать изменения из нужной удаленной ветки юзаю команду git pull --rebase origin remote_branch

[@sailent1986]

Сделайте відео как правельно резолвить конфлікти в qa, master і тд

[@frontendscience]

Да есть в планах снять видео про резолв конфликтов

[@nazariihond6503]

merge

[@Bob-fh6jb]

А что это за классная книга с котиками?

[@frontendscience]

girliemac.com/blog/2017/12/26/git-purr/