@@рострост-м6з И на джуна и на мидла. Я их много проходил. Некоторые компании (например Luxoft, Epam) сначала проводят жёсткий собес, а потом на его основании определяют твой уровень.
@@frontendscience в прошлом видео видел, что ты используешь элиас lg для вывода гит лога. Какие ещё используешь? Я кроме lg ещё last добавил себе для вывода последнего коммита. Спасибо!
Правила просты - соблюдайте их и будет вам ЩАСТЕ: - НИКТО и НИКОГДА не пихает коммиты (push) в чужие ветки - делайте СВОЙ бранч и работайте там спокойно (напомню, что её даже пушить - не обязательно если работаете один). - В СВОЮ ветку для получения изменений извне лучше делать Rebase, в любую чужую - не важно чью, не говоря уже про базовые master/develop - только Merge - иначе вам придут и сломают лицо. Из этого следует: когда над фичей работают несколько разработчиков - делается отдельная feature-ветка, после чего каждый из них ОБЯЗАН сделать СВОЁ собственное ответвление от этой feature-ветки (Branch) и продолжать работать по стандартным правилам, договариваясь отправляя сообщения: "я сегодня сделаю merge в основную feature ветку - есть возражения?" И после успешного MERGE - второе: "Ребята, я сделал merge в feature ветку - обновитесь".
@@basvalan Наличие процесса pull requests - зависит от договорённостей и метода разделения ответственности в команде. Ну и от настроек, которые, иногда, некому делать.
Знал, что rebase этот мерж только по-другому, но как именно по другому не понимал (описания до этого читал перемудреные). После этого видео все стало понятно, спасибо!
Работаем по разному, но в основном через merge из-за надежности. Когда бывает очень много малозначимых коммитов , например исправление опечаток в словах, тогда обычно мы делаем squash или интерактивный rebase, но видимо это следующее видео в цикле Git :) PS: спасибо за труды, новичков в команде часто приходится подтягивать поэтому советую что посмотреть и с какого канала, у вас достойные и наглядные объяснения - буду советовать.
Наконец-то)) спасибо вам, очень хорошо объяснили, я до этого читала. И никак не могла понять. У меня скопилось много разных версий. Так и жила несколько лет 😀. Документацию к гиту писал какой - то душнила, чтоб было максимально непонятно и запутанно.
Чел, отличное видео! Благодаря ему я всё же понял, когда и что использовать. Большинство говорит, что эти команды делают, но когда их использовать чётко - мало кто)
Да. Спасибо Сергей. Всегда хватало merge, но не давно начал искать работу и не знал даже что существует такая команда как rebase. Я просто и сказал так что не знаю - в результате не прошёл, но поинтересовался. Греет душу что не упал всё таки лицом в грязь, так как это фактически аналоги.
Спасибо большое за объяснение. Первый раз на вашем канале и сразу же подписалась. Доходчивое объяснение со схемами. И отдельный респект за вставки различных мемов, гифок и "красивометр" 😁. Это помогает взбодриться и смотреть видео с бОльшей концентрацией.
мне тоже зашли мемы, гифки и красивометр 😁 хотя когда появился красивометр, я наоборот немного потеряла концентрацию, по большей части от забавности ситуации 😆
7:15 - застешил локальные изменения потом спулил из ветки ребезнутую другим девом версию и поверх анстешнул ну или на худой конец можно черипикнуть, не вижу проблем
1. Застешить не выйдет. Из примера в видео я сказал что уже коммиты в своей ветке есть. 2. В видео я привел решение - делать пул с ребейзом всегда: git pull --rebase origin feature 3. Для того чтобы это работало надо обязательно внутри команды договориться о flow по которому все без исключения будут работать.
Всё-таки можно посмотреть в какие моменты "подобновляли" свою ветку. Нужно ребейз делать с флагом --committer-date-is-author-date Но это и не важно (дата обновления). Важна лишь последовательность и дата, когда данный коммит попал в общую ветку, т.е. повлиял на других.
Добрый вечер! По моему, не было сказано, что при команде "git rebase master" (т.е. при вставке текущей feature-ветки в конец master-ветки), коммиты feature-ветки не будут видны в master-ветке (т.е. они как бы останутся изолированными). И чтобы их объединить надо выполнить команду (из master-ветки): "git merge feature".
Если я правильно понял, то итог таков: если я один на веткой работаю, то лучше через rebase брать обновления с master, а если несколько человек работают в одной веткой, то merge.
Я новичок и как раз задался этим вопросом. Ваш ответ очень доходчив, спасибо. Подписался. Я работал один в своей ветке, несколько раз уже делал рибэйз (git checkout dev / git pull / git checkout feature, / git rebase dev), но, с каждым новым таким рибэйзом мне прилетает все больше кофликтов, где надо вручную их разрешать, хотя мои коммиты не затрагивают файлы основной ветки dev. Техлид просто посоветовал делать merge и не использовать rebase.
Могу посоветовать один метод который поможет или вообще избавиться от конфликтов или их прийдется решить один раз. Перед тем как делать ребейз нужно сосквашть (склеить) все комиты в фичеветке.
Невероятно, Сергей, я думал вы из России, помню видео где вы над проектом ВКонтакте работали, а сейчас узнал, что вы из Украины, очень здорово, что такой крутой человек поддерживает Украину❤ удачи вам в будущем
О! Годнота подъехала! Спасибо тебе! На позапрошлом месте работы, работая на одном проекте, у тимлида жёстко подгорало, когда он видел мерж-коммиты в моих мерж-реквестах., приходилось ребейсить. Но нас в команде было двое. Потом перевели на другой проект, где в одном репозитории были и фронт и бэк. Я по привычке сделал ребейс, запушил, а потом вместе с бэкендером, работающем с данной веткой пытались разобраться в получившейся каше. А вообще, как думаешь, хорошая практика - фронт и бэк в одном репозитории?
ОООО..... это очень холиварный вопрос. Тут очень много зависит от самого проекта и еще от частоты обновления, важности синхронизации бакенда и фронтенда и др. Я лично за более микросервисную архитектуру и разделение ответсвенности. Но есть много проектов где такой подход не пройдет. Так что - как говорят it depends. PS: на последок рекомендую для общего развития поискать в интернете информацию про monorepo подход. Самый крупный монорепо в Мире например у Гугла - весь код всего лежит в одном репозитории.
1 проект - 1 репозиторий. Фронт это один проект. апи сервера это другие проектЫ. Т.е. репозиториев должно быть ни менее 2. Два апи+фронт = 3 репозитория.
@@olezhonnv3215 до поры до времени, пока 10 человек с разными целями не попытаются это всё смержить и куча конфликтов либо кривой автомрж всё не похерит. Уже проходили.
Если Вы меняете историю и она отличается от той, что на внешнем сервере, то да, только форс пуш. Иначе гит не даст Вам отправить это на внешний сервер. Если Вы разрабатываете локально и делаете ребейз и никуда еще ничего не пушили, то можно и дальше делать коммиты, ребейзы, а потом один раз отправить ветку на удаленный сервер.
Привет. Спасибо за видео. Я только начал изучать и у меня может странный вопрос. Если я находясь в ветке "фича" сделаю git merge main, то разве моя ветка "фича" не станет единственной и главной? Я думаю это не по православному и нужно мержить свою ветку в "мейн". Я ошибаюсь?
А если я несколько раз буду обновлять свою фича ветку разными (обновленными) мастерами, то эти мастера в конфликт не войдут между собой? и не будут ли каждый раз заново добавляться к моей фича вет ке? не окажется ли перед моей фичой после нескольких обнновлений 5-6 мастеров разных версий?
Если сделать git pull origin master, то будет сделан merge commit в ветке со свежими изменениями из мастера. А если сделать git pull --rebase origin master то тогда ветка будет отребейжена от мастера
но ведь токийская схема метро получается не потому, что merge Такой, а потому что коммитят каждый раз как захотят, нет? например, если бы договорились раз в неделю забирать свежий мастер и пилить фичу до следующей недели? понятно, что могут быть багфиксы, но разве в этом случае схема метро не стала бы меньше?
Метро получается из-за того что при "подмерживании" мастера в фичеветку - получается дополнительный коммит. Я лично не любитель этого, но знаю много разработчиков которые к "метро" замечательно относятся!
На всех собесах, где спрашивали Git, обязательно спрашивали этот вопрос (в теме видео). Спасибо за доходчивое объяснение!
Ухты класс! Не знал что такое на собеседованиях спрашивают. Рад что было полезно!
Собесы на джуна?
@@рострост-м6з И на джуна и на мидла. Я их много проходил. Некоторые компании (например Luxoft, Epam) сначала проводят жёсткий собес, а потом на его основании определяют твой уровень.
+ мне пару дней назад задали этот вопрос, но до этого я уже посмотрел это видео и ответил на вопрос более менее удачно 🙃
У меня это спросили в епаме на собесе для лабы. Я помнила только что ребейз плохо, а мерж хорошо :D
Спасибо! Всегда делал мердж, но после просмотра видео понял, что можно и рибэйз использовать)
Рад что было полезно!
@@frontendscience в прошлом видео видел, что ты используешь элиас lg для вывода гит лога. Какие ещё используешь?
Я кроме lg ещё last добавил себе для вывода последнего коммита.
Спасибо!
Правила просты - соблюдайте их и будет вам ЩАСТЕ:
- НИКТО и НИКОГДА не пихает коммиты (push) в чужие ветки - делайте СВОЙ бранч и работайте там спокойно (напомню, что её даже пушить - не обязательно если работаете один).
- В СВОЮ ветку для получения изменений извне лучше делать Rebase, в любую чужую - не важно чью, не говоря уже про базовые master/develop - только Merge - иначе вам придут и сломают лицо.
Из этого следует: когда над фичей работают несколько разработчиков - делается отдельная feature-ветка, после чего каждый из них ОБЯЗАН сделать СВОЁ собственное ответвление от этой feature-ветки (Branch) и продолжать работать по стандартным правилам, договариваясь отправляя сообщения: "я сегодня сделаю merge в основную feature ветку - есть возражения?" И после успешного MERGE - второе: "Ребята, я сделал merge в feature ветку - обновитесь".
У вас там что-то о пул реквестах слышали?
@@basvalan Наличие процесса pull requests - зависит от договорённостей и метода разделения ответственности в команде.
Ну и от настроек, которые, иногда, некому делать.
Все чаще возвращаюсь на этот канал для заполнения пробелов в своих знаниях.
Рад слышать:) успехов Вам!
Очень красивое видео, прям как елочка.
Спасибо за видео
Старалси :)
Мне тоже понравился момент с елочкой 👍
посмотрел 5 видео по этой теме, только на вашем понял. спасибо, подписался
Очень вдохновляет! Спасибо за обратную связь! Будем еще больше стараться)
Знал, что rebase этот мерж только по-другому, но как именно по другому не понимал (описания до этого читал перемудреные). После этого видео все стало понятно, спасибо!
Лайк. Чистый вопрос на собеседовании. Плюс хорошее объяснение для понимания. Спасибо большое. Подписка.
Огромное спасибо за видео. Наконец-то получилось найти простое и доступное объяснение про эти команды.
И Вам спасибо! )
На собесах для мидлов задают такие вопросы.
Огромное спасибо автору за простое и полное объяснение!
Работаем по разному, но в основном через merge из-за надежности. Когда бывает очень много малозначимых коммитов , например исправление опечаток в словах, тогда обычно мы делаем squash или интерактивный rebase, но видимо это следующее видео в цикле Git :)
PS: спасибо за труды, новичков в команде часто приходится подтягивать поэтому советую что посмотреть и с какого канала, у вас достойные и наглядные объяснения - буду советовать.
Как же доступно автор всё объяснил! Спасибо!
Дай тебе Бог здоровья, хлопчик, наконец-то дошло до старика.
Спасибо.
4:23 rebase (состав + состав) Одному разрабу на ветке самый раз. Многим разрабам нужно осторожно так как меняется история и hash коммитов.
Нраицца. Спасибо. Использую merge постоянно. Теперь готов попробовать rebase
Класс! Спасибо)
пользуюсь только merge, как раз потому что не имел ни одного проекта, который разрабатывал бы один
отличный материал, спасибо!
рассказ про ветки же
одна ветка на проект?
Наконец-то)) спасибо вам, очень хорошо объяснили, я до этого читала. И никак не могла понять. У меня скопилось много разных версий. Так и жила несколько лет 😀. Документацию к гиту писал какой - то душнила, чтоб было максимально непонятно и запутанно.
Супер! Очень доходчиво! Отдельное спасибо за вставки картинок и гифок! Поржал))))
Прикольно! Рад, что понравилось! Я старался))
Благодаря этому видео, вопрос по мерджу/ребейзу для себя закрыл. Очень доходчиво объяснил. Дякую!;)
Оочень четкое и понятное объяснение! Большое Вам спасибо!
Объяснение merge и rebase на котиках это же гениально!))
Спасибо за видео! Отличное объяснение отличий, плюсов и минусов обоих методов.
И Вам спасибо, что смотрите! Рады стараться.
братан не знаю как но ты самый понятнее всего обьяснил из всего простора инета
Cпасибо, мне как начинающему разработчику было очень полезно!
Очень рад. Благодарю, что написали.
Спасибо, за доступное объяснение!
Чел, отличное видео! Благодаря ему я всё же понял, когда и что использовать. Большинство говорит, что эти команды делают, но когда их использовать чётко - мало кто)
Рад, что пригодилось, бро)
Да. Спасибо Сергей. Всегда хватало merge, но не давно начал искать работу и не знал даже что существует такая команда как rebase. Я просто и сказал так что не знаю - в результате не прошёл, но поинтересовался. Греет душу что не упал всё таки лицом в грязь, так как это фактически аналоги.
Самое доходчивое объяснение ! спасибо!
Рад, что оказалось полезно)
Спасибо большое за объяснение.
Первый раз на вашем канале и сразу же подписалась.
Доходчивое объяснение со схемами. И отдельный респект за вставки различных мемов, гифок и "красивометр" 😁. Это помогает взбодриться и смотреть видео с бОльшей концентрацией.
мне тоже зашли мемы, гифки и красивометр 😁 хотя когда появился красивометр, я наоборот немного потеряла концентрацию, по большей части от забавности ситуации 😆
Отлично объяснил, спасибо Сергii 👍
Классно объясняете, понятно. Спасибо большое!
Супер!!! Самое лучшее объяснение, все просто и ясно, спасибо)))
И Вам спасибо)
Спасибо, очень доходчиво и на котиках. Успехов!
7:15 - застешил локальные изменения потом спулил из ветки ребезнутую другим девом версию и поверх анстешнул ну или на худой конец можно черипикнуть, не вижу проблем
1. Застешить не выйдет. Из примера в видео я сказал что уже коммиты в своей ветке есть.
2. В видео я привел решение - делать пул с ребейзом всегда: git pull --rebase origin feature
3. Для того чтобы это работало надо обязательно внутри команды договориться о flow по которому все без исключения будут работать.
Благодарю тебя добрый человек!
Спасибо, дошло!
Отличный видос, без воды по полочкам, спасибо
Рад, что было полезно
Всё-таки можно посмотреть в какие моменты "подобновляли" свою ветку. Нужно ребейз делать с флагом --committer-date-is-author-date Но это и не важно (дата обновления). Важна лишь последовательность и дата, когда данный коммит попал в общую ветку, т.е. повлиял на других.
Самое ёмкое и понятное объяснение😍 Спасибо!
Наконец-то я понял что за rebase. Спасибо!
Класс! Рад, что помогло!
Крутое видео и канал ооочень интересный, я очень надеюсь, что не забросишь, а будешь только дальше развиваться, спасибо!
Благодарю за поддержку! Рад, что оказалось полезно)
А чтобы подобновить свою ветку, нужно ведь master подтянуть сначала git pull?
Спасибо, очень понятно)
Сопроводительные вставки повеселили, и я даже походу понял как это работает)
Спасибо, отличное наглядное объяснение!
Рад, что было полезно! Спасибо за поддержку
Git pull master тоже делает merge?
👍👍👍 вообще огонь!
Нормальное объяснение ребейса, Наконец-то!
Рад, что оказалось полезно!
Крутой материал!
Вот теперь всё понятно, спасибо!
Добрый вечер! По моему, не было сказано, что при команде "git rebase master" (т.е. при вставке текущей feature-ветки в конец master-ветки), коммиты feature-ветки не будут видны в master-ветке (т.е. они как бы останутся изолированными).
И чтобы их объединить надо выполнить команду (из master-ветки): "git merge feature".
💯✨💯✨Идеально объяснил
Рад, что было полезно)
Спасибо большое! Мега-понятно !
Рад, что оказалось полезно! Спасибо, что смотрите)
при колективній роботі на одній гілці можна ж користуватися методом git fetch + git rebase потім git push
Здарово Серег. Спасибб
спасибо огромное! все понятно и четко
а чем git merge master отличается от git pull origin master ? у нас в компании через pull origin под обновляют ветку
pull стягивает и мержит. А merge - мержит локальную ветку с локальной (без стягивания).
Полезно) спасибо за видео вам
великолепное объяснение и прекрасная подача материала! спасибо!
Супер объяснение! а можно такое же объяснение для - git squash?
Очень хорошее видео, спасибо!
И Вам спасибо ;)
Спасибо, очень понятно, топ!
Наконец то я стал понимать о чем речь!
Рад что оказалось полезным!
Спасибо большое за крутой контент. Очень информативно и понятно
И Вам спасибо! ) Рад, что пригодилось
Гениально!
Благодарю! 👍
А если делать всегда merge, но в какой то момент в конце сделать сквош, получиться же один коммит на задачу
Подскажите откуда картинка ближе к концу со схемой котами)
Из интернета. Она у меня в архиве очень давно лежит.
girliemac.com/blog/2017/12/26/git-purr/
Круто! А можно ребейз откатить? Если при ребейзе неправильно решены конфликты
Лучшее объяснение! 👍
можно ли добавлять фичу в мастер через рибейз? или это только для обновления?
О круто. Не использовал даже. Спасибо
Контекст вызова this, простым языком будет видео?
Если есть запрос - да, сделаем :) Спасибо за идею!
спасибо за объяснение
Если я правильно понял, то итог таков: если я один на веткой работаю, то лучше через rebase брать обновления с master, а если несколько человек работают в одной веткой, то merge.
Да, все верно.
@@frontendscience Благодарю Вас за видео!
@@temik26 И Вам спасибо за просмотр!
Отличное объяснение, спасибо!
Я новичок и как раз задался этим вопросом. Ваш ответ очень доходчив, спасибо. Подписался. Я работал один в своей ветке, несколько раз уже делал рибэйз (git checkout dev / git pull / git checkout feature, / git rebase dev), но, с каждым новым таким рибэйзом мне прилетает все больше кофликтов, где надо вручную их разрешать, хотя мои коммиты не затрагивают файлы основной ветки dev. Техлид просто посоветовал делать merge и не использовать rebase.
Могу посоветовать один метод который поможет или вообще избавиться от конфликтов или их прийдется решить один раз. Перед тем как делать ребейз нужно сосквашть (склеить) все комиты в фичеветке.
Про то как склеить комиты расскажу в следующем видео
@@frontendscience ну давай до конца уж. Как команда выглядит?
@@frontendscience Интриган :)))
interactive rebase
Невероятно, Сергей, я думал вы из России, помню видео где вы над проектом ВКонтакте работали, а сейчас узнал, что вы из Украины, очень здорово, что такой крутой человек поддерживает Украину❤ удачи вам в будущем
Все понятно, спасибо
о, спасибо теперь понятно что и когда
Супер! Очень рад!
О! Годнота подъехала! Спасибо тебе!
На позапрошлом месте работы, работая на одном проекте, у тимлида жёстко подгорало, когда он видел мерж-коммиты в моих мерж-реквестах., приходилось ребейсить. Но нас в команде было двое.
Потом перевели на другой проект, где в одном репозитории были и фронт и бэк. Я по привычке сделал ребейс, запушил, а потом вместе с бэкендером, работающем с данной веткой пытались разобраться в получившейся каше.
А вообще, как думаешь, хорошая практика - фронт и бэк в одном репозитории?
ОООО..... это очень холиварный вопрос. Тут очень много зависит от самого проекта и еще от частоты обновления, важности синхронизации бакенда и фронтенда и др. Я лично за более микросервисную архитектуру и разделение ответсвенности. Но есть много проектов где такой подход не пройдет. Так что - как говорят it depends. PS: на последок рекомендую для общего развития поискать в интернете информацию про monorepo подход. Самый крупный монорепо в Мире например у Гугла - весь код всего лежит в одном репозитории.
1 проект - 1 репозиторий. Фронт это один проект. апи сервера это другие проектЫ. Т.е. репозиториев должно быть ни менее 2. Два апи+фронт = 3 репозитория.
@@olezhonnv3215 до поры до времени, пока 10 человек с разными целями не попытаются это всё смержить и куча конфликтов либо кривой автомрж всё не похерит. Уже проходили.
Спасибо! Все понятно!
Рад слышать 👍
Подскажите, после ребейза можно/нужно только форсе-пушить? всегда? а если еще один ребейз? тоже теперь только форс-пуш?
Если Вы меняете историю и она отличается от той, что на внешнем сервере, то да, только форс пуш. Иначе гит не даст Вам отправить это на внешний сервер. Если Вы разрабатываете локально и делаете ребейз и никуда еще ничего не пушили, то можно и дальше делать коммиты, ребейзы, а потом один раз отправить ветку на удаленный сервер.
Привет. Спасибо за видео. Я только начал изучать и у меня может странный вопрос. Если я находясь в ветке "фича" сделаю git merge main, то разве моя ветка "фича" не станет единственной и главной? Я думаю это не по православному и нужно мержить свою ветку в "мейн". Я ошибаюсь?
спасибо!
Спасибо, полезно
А если я несколько раз буду обновлять свою фича ветку разными (обновленными) мастерами, то эти мастера в конфликт не войдут между собой? и не будут ли каждый раз заново добавляться к моей фича вет
ке? не окажется ли перед моей фичой после нескольких обнновлений 5-6 мастеров разных версий?
респект, красавчик
крутое объяснение, спасибо!
Использую всегда merge, в проектах несколько разрабов, поэтому безопасность превыше эстетики)
Спасибо огромное)
И Вам! )
Класс, благодарю, супер понятно!
Рад, что оказалось полезно!)
Нельзя использовать git pull origin master ? Для обновления
Если сделать git pull origin master, то будет сделан merge commit в ветке со свежими изменениями из мастера. А если сделать git pull --rebase origin master то тогда ветка будет отребейжена от мастера
Спасибо за контент!
И Вам спасибо :)
Спс, за обьяснения. Я всегда боялся ребейза. Я толком даже и мердж не юзал - всегда писал git pull origin branch...Спс за обьяснение
Класс! Рад, что оказалось полезным!
А откуда взяли картинки объяснения Гита с котиками?
girliemac.com/blog/2017/12/26/git-purr/
Достойно лайка
А где взять такой конспект с котиками?
Отсылка на красивометре "142" из "Автостопом по галактике" ?
Можно и так сказать! Тока там было просто 42
но ведь токийская схема метро получается не потому, что merge Такой, а потому что коммитят каждый раз как захотят, нет? например, если бы договорились раз в неделю забирать свежий мастер и пилить фичу до следующей недели? понятно, что могут быть багфиксы, но разве в этом случае схема метро не стала бы меньше?
Метро получается из-за того что при "подмерживании" мастера в фичеветку - получается дополнительный коммит.
Я лично не любитель этого, но знаю много разработчиков которые к "метро" замечательно относятся!
А в чем разница между merge and rebase?
Когда я вижу git checkout feature у меня возникает ассоциация, что эта команда существует для выхода из ветки, а для входа нужна команда git checkin
Наверное многие видели такое, поэтому сделали команду git switch. Она меняет ветку )