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