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