БЕСПЛАТНЫЙ ВЕБ "Рынок труда в 2025 для Java Junior без опыта" 23 октября в 19:00 по МСК! Разберем, что ждет джунов в будущем году, какие требованиях и, что будет с зарплатами. ЗАРЕГИСТРИРОВАТЬСЯ: www.faang.school/vebinar-job-market-2025?
11:55 - вроде надо git merge для этого использовать, а не git rebase. Git rebase перезаписывает старые коммиты новыми и поэтому меняются хеши, а это боль для дальнейшей разработки в команде.
rebase же может как перезаписывать историю, так и просто сделать "перемотку" вперёд. Если сделали ответвление от мастера, в ней (новой ветке) завершили создавать новую фичу и при этом, после момента ответвления в мастер не было сделано новых коммитов, то выгоднее сделать rebase, чем merge, который создаст новый "коммит ради коммита" rebase в этом случае просто перенесёт метку master на завершающий коммит, в котором создавалась новая фича. Словно все коммиты, от момента ветвления, делались в мастер.
про rebase вообще чушь наговорил какую-то. если мы на фича-ветке, сделали rebase master, то master никак не затронется. фича-ветка действительно перенесется на последний коммит из master, но это лишь изменит саму фича-ветку (в неё добавятся недостающие мастер коммиты), в ветку master новых коммитов не добавится. если переносить коммиты с фича-ветки на мастер, то надо перейти на мастер и сделать rebase feature. а вообще я никогда не видел, чтобы ребейз для слияния в основную ветку использовали. обычно через мёрдж, чтобы создавался мёрдж коммит, и в случае чего можно было сделать revert на один этот коммит, а не отменять n коммитов с фича ветки.
корректное замечание, Влад добавь мерж - это на много популярнее ребэйс + иногда мы пользуемся черри-пик и еще реже аменд - тогда это будет действительно 100% всех случаев
1. Еще в начале ролика поставил лайк потому что видео реально полезное, без воды и прочей бурды. 2. На протяжении ролика раз 10 ставик лайк забыв что уже поставил. 3. А почему в гитхабе не сделать визуальное оформление веток?!?!? с функционалом - нажал на нужный кружок - вот тебе весь его код и файлы, вышел обратно, следующий нажал, вот тебе его код и что добавлено в сравнении с предыдущим кружком, это ведь реально мега удобно и просто, чем листать список
Ты первый автор, которого я смотрю в скорости 0.75, чтобы улавливать 100% )) Обычно смотрю в 1.5. Отличный, и главное, понятный материал. Подписался и лайк прожал!
Насчет добавления всех файлов через git add, я как то сталкивался с проблемами, уже не скажу какими, но по итогу взял себе за привычку юзать git add -A. Этот параметр явно говорит гиту добавить все без точек и звездочек
Даров) недавно наткнулся на твой канал, все очень круто преподносишь, прям по полочкам, однозначно подписка. Когда можно ждать видео про Кубер? Видел, что люди давно просят)
норм спс круто топ пойдет ну хороший видос тип норм, снимай еще , го че нить интересное сними пж , мб про лямбды и стримы было бы норм видос интересный, го лямбды и стримы
Чтобы создать ветку и сразу в неё перейти достаточно одной команды git checkout -b {branch_name}. Ну и использовать rebase вместо merge - это может быть жестоко (пример из жизни: забивать молотком шуруп).
Еще не много хотел дополнить Для создания новой бранчи и перехода на нее можно использовать git checkout -b Еще есть полезная команда для подгрузки изменений с основной ветки на вашу с так называемым решение конфликтов у нас есть 3 основные ветки dev stage master и вот если кто то замерджил изменения в dev и вы хотите что бы они подгрузились на вашу ветку можно использовать комануд git pull origin dev --rebase И еще git rev-parse HEAD нужно для того что бы Получить хеш последнего коммита например для загрузки в другой репозиторий.
git rebase используется для того, что бы подтянуть историю. А что бы в основную ветку внести правки нужен git merge. Git rebase нужен обычно если мы в отдельной ветке сделали новые правки потом смержили в мейн и после этого прошло время и мы вернулись к фиче которую над доработать но и нужно подтянуть изменения из основной ветки
Спасибо, очень крутой ролик! Очень наглядно, доходчиво, не скучно. Но что насчет команды git merge? Ее не упомянули. Что если я не хочу переносить всю ветку с коммитами в основную, а хочу сохранить ее, чтобы было видно над чем в какой ветке работали (тоже самое и с другими доп. ветками), а просто хочу подсоединить последний коммит данной ветки к основной ветке? Для этого, насколько я помню как раз и используется git merge (чтобы объединить коммиты из разных веток). 14:28 Но что если я полностью хочу удалить старый коммит?
Чтобы удалить коммит так чтобы он не остался в истории, то можно сделать интерактивный rebase, и в редакторе vim на нужно коммите написать drop. Не благодарите)
Я щитаю надо было 12 делать: merge и cherry-pick - тоже весьма важные команды, особенно если у сеньора пунктик - "1 ветка, 1 коммит", а иначе кровь из глаз у него идет. (из личной практики) upd. туда же squash
Поправьте, если не прав, но чтобы добиться поведения описанного в разделе git rebase в видео надо проделать следующие шаги: 1. git checkout feature (переходим в ветку feature, чтобы на 2 шаге сделать так чтобы первый коммит этой ветки оказался от последнего коммита ветки main/master) 2. git rebase main (переносим первый коммит наш, как будто мы сделали его от последнего актуального коммита в ветке main (предварительно ветку main надо подобновить, я обычно делаю git fetch и потом git rebase origin/dev, примерно такую конструкцию). Здесь ещё стоит уточнить, что если есть конфликты, то их придётся решить для каждого коммита в ветке feature (где затрагиваются эти изменения), а для новичка это, возможно, вызовет много проблем). А также важно то, что хеш наших коммитов в feature ветке изменится, и если над feature работаем не только мы, это может быть очень плохо, так что делайте rebase-ы только если один работали над feature 3. git checkout main (переходим на main) 4. git rebase feature (не делал ни разу, но в теории должно произойти поведение описанное в видео) В целом мы на работе используем rebase, чтобы сохранить «красивый» git graph прямо перед созданием мердж реквестов, и так более структурно понятно кто какие изменения внёс и остаётся возможность откатиться на один коммит, если такое требуется
@@lidiagodo7622 Пункт с main - это из ролика (пошаговое объяснение того, что нужно сделать, чтобы добиться поведения с видео ) А в скобочках я там просто хотел показать как обычно происходит этот процесс в работе, мы в main впринципе льём изменения только через UI удаленного репозитория, поэтому чаще всего rebase (у меня лично в работе) выглядит как сочетание этих двух команд (git fetch и git rebase origin/dev)
Друг, говоришь о rebase нужно явно рассказать почему используешь в "своей ветке" ибо это важный нюанс о котором ни слова. Тут 15 мин об основных коммандах явно мало времени для обьяснения.
Неправильное понимание гит ребейза. Он нужен для другого. Гит ребейз от мастера иногда делается перед отправкой локальной ветки на влитие в мастер, если у тебя по задаче было много коммитов, а хочется, чтоб они не перемешались с чужими коммитами, которые уже есть в мастере (влились одной кучкой, по порядку). Мы делаем git fetch && git rebase origin/master, гит подтягивает все недостающие коммиты из мастера, а твои личные коммиты переносит в конец истории. Иногда это сопровождается разрешением конфликтов, если правки чужих коммитов связаны с теми же частями кода, что в твоих. После этого можно пушить свою ветку и отдавать её на заливку в мастер. Если не требуется такой перенос своих коммитов в конец истории, то можно делать git pull origin/master или git merge origin/master перед пушем.
merge твою ветку не переносит а просто сливает в месте последнего коммита. Rebase же переносит место (по сути первый а не последний твой коммит) где ты отколол свою ветку в указанное тобой место.
Это нормально использовать ребейз в командной разработке? А потом удивляться фингалу под глазом от других разработчиков? Ты сделал ребейз и отменил все наработки своего коллеги. Потом коллега тебе дал по мордесам, выдал ручку и тетрадку которую ты должен заполнить фразой "При командной разработке я делаю мерж а не ребейз" и так 1000 раз чтоб запомнил.
БЕСПЛАТНЫЙ ВЕБ "Рынок труда в 2025 для Java Junior без опыта" 23 октября в 19:00 по МСК! Разберем, что ждет джунов в будущем году, какие требованиях и, что будет с зарплатами. ЗАРЕГИСТРИРОВАТЬСЯ: www.faang.school/vebinar-job-market-2025?
не получается зарегистрироваться на вебинар, нет формы регистрации.
Блинский, только заметил видос, а оказывается уже и вебинар прошёл и Шпаргалки не открываются(
кто тоже хочет видео про elk, reids, kubernates, ставьте лайк, посмотрим сколько нас
Elk не актуально😢, нужен open search
Влад ты МОЛОДЕЦ - очень простые и понятные уроки о СЛОЖНЫХ ВЕЩАХ!
Влад, это шикарное видео! Ты молодец. Спасибо за работу с анимацией и продуманный сценарий
11:55 - вроде надо git merge для этого использовать, а не git rebase.
Git rebase перезаписывает старые коммиты новыми и поэтому меняются хеши, а это боль для дальнейшей разработки в команде.
ага, автор спутал merge и rebase
Ну оба подхода возможны. Мы из фича-веток мержим в дев, а вот в мастер уже ребейс и сплющить после ревью) так уж повелось
@@SvyatoyVitaliy мы только из мастера в свою ветку подтягиваем изменения через git rebase
rebase же может как перезаписывать историю, так и просто сделать "перемотку" вперёд.
Если сделали ответвление от мастера, в ней (новой ветке) завершили создавать новую фичу и при этом, после момента ответвления в мастер не было сделано новых коммитов, то выгоднее сделать rebase, чем merge, который создаст новый "коммит ради коммита"
rebase в этом случае просто перенесёт метку master на завершающий коммит, в котором создавалась новая фича. Словно все коммиты, от момента ветвления, делались в мастер.
@@balaamstermerge fast forward сделает в этом случае то же, что и rebase
Офигенно сделано видео!
Спасибо за такую подачу материала, на простом объяснении и графическом подкреплении!!!
про rebase вообще чушь наговорил какую-то. если мы на фича-ветке, сделали rebase master, то master никак не затронется. фича-ветка действительно перенесется на последний коммит из master, но это лишь изменит саму фича-ветку (в неё добавятся недостающие мастер коммиты), в ветку master новых коммитов не добавится. если переносить коммиты с фича-ветки на мастер, то надо перейти на мастер и сделать rebase feature. а вообще я никогда не видел, чтобы ребейз для слияния в основную ветку использовали. обычно через мёрдж, чтобы создавался мёрдж коммит, и в случае чего можно было сделать revert на один этот коммит, а не отменять n коммитов с фича ветки.
корректное замечание, Влад добавь мерж - это на много популярнее ребэйс
+ иногда мы пользуемся черри-пик и еще реже аменд - тогда это будет действительно 100% всех случаев
У него давно было видео, он по-моему об этом говорил. Скорее всего забыл или просто оплошал.
Отлично 👌 коротко и ясно, без "воды", красавчик👍
Какой классный канал я сегодня нашла 😻
Уже 4 видео и все полезные !!
Браво! Мой брат учит разработку, и это видео помогло ему понять концепции гита.
Молодец! Отличное видео, отличные анимации, прямо как надо!
Урааааа, новое видео Влада. Как же я рада) Влад, ты самый лучший учитель)
- Сколько рекламы будет в видео?
- Да.
git stash ещё
Я без него не выжил бы 🥲
А него скакать от задачи к задаче 😅😅😅
Круто! Спасибо 👍
А ещё просим видео про Redis! RE-DIS! RE-DIS!
Поступил в универ и по плюсам мы сдаем задания именно через гитхаб, большое спасибо за такое своевременное видео хахах
Крутой видос! Спасибо!
Спасибо тебе. Очень класное и поучительное видео👍
1. Еще в начале ролика поставил лайк потому что видео реально полезное, без воды и прочей бурды.
2. На протяжении ролика раз 10 ставик лайк забыв что уже поставил.
3. А почему в гитхабе не сделать визуальное оформление веток?!?!? с функционалом - нажал на нужный кружок - вот тебе весь его код и файлы, вышел обратно, следующий нажал, вот тебе его код и что добавлено в сравнении с предыдущим кружком, это ведь реально мега удобно и просто, чем листать список
Ты первый автор, которого я смотрю в скорости 0.75, чтобы улавливать 100% )) Обычно смотрю в 1.5. Отличный, и главное, понятный материал. Подписался и лайк прожал!
Абсолютно идентично!😂
Спасибо за видео)
Обясняешь лучше всех!
Лайк ❤
Спасибо, всё понятно!
Спасибо, столкнулся с такой проблемой как создание SSH ключа. Очень много времени потратил что бы сделать сертификат.
I am waiting your videos every day :)
Насчет добавления всех файлов через git add, я как то сталкивался с проблемами, уже не скажу какими, но по итогу взял себе за привычку юзать git add -A. Этот параметр явно говорит гиту добавить все без точек и звездочек
Hartelijk dank, Vlad!
Вовремя, только собирался начать учить 😊
Привет Влад, очень жду один день программиста!
Хорошее видео)
Влад, я тебя обожаю. ❤
Комент в поддержку
Даров) недавно наткнулся на твой канал, все очень круто преподносишь, прям по полочкам, однозначно подписка. Когда можно ждать видео про Кубер? Видел, что люди давно просят)
Спасибо большое
Блин... Хорош 🎉🎉🎉🎉
Видео как по заказу, лайк коммент чмок в лобик
ЛУЧШИЙ!!!
хэлло Владос) начинаю учить джаву
9:07 А можно сразу прописывать git checkout -b
Для тех кто не знает разницу между rebase и merge: Вам даже Влад объяснил как используется rebase (перенос коммитов). Нет ошибки
норм спс круто топ пойдет ну хороший видос тип норм, снимай еще , го че нить интересное сними пж , мб про лямбды и стримы было бы норм видос интересный, го лямбды и стримы
Чтобы создать ветку и сразу в неё перейти достаточно одной команды git checkout -b {branch_name}. Ну и использовать rebase вместо merge - это может быть жестоко (пример из жизни: забивать молотком шуруп).
У Влада лучшие видео по гиту на русскоязычном Ютубе
Еще не много хотел дополнить
Для создания новой бранчи и перехода на нее можно использовать git checkout -b
Еще есть полезная команда для подгрузки изменений с основной ветки на вашу с так называемым решение конфликтов у нас есть 3 основные ветки dev stage master
и вот если кто то замерджил изменения в dev и вы хотите что бы они подгрузились на вашу ветку можно использовать комануд git pull origin dev --rebase
И еще git rev-parse HEAD нужно для того что бы Получить хеш последнего коммита например для загрузки в другой репозиторий.
git rebase используется для того, что бы подтянуть историю. А что бы в основную ветку внести правки нужен git merge. Git rebase нужен обычно если мы в отдельной ветке сделали новые правки потом смержили в мейн и после этого прошло время и мы вернулись к фиче которую над доработать но и нужно подтянуть изменения из основной ветки
Вижу Canva хорошо помогает в создании видео😅
Это именно то, что мне нужно было. Спасибо, Влад!
Спасибо, очень крутой ролик! Очень наглядно, доходчиво, не скучно. Но что насчет команды git merge? Ее не упомянули. Что если я не хочу переносить всю ветку с коммитами в основную, а хочу сохранить ее, чтобы было видно над чем в какой ветке работали (тоже самое и с другими доп. ветками), а просто хочу подсоединить последний коммит данной ветки к основной ветке? Для этого, насколько я помню как раз и используется git merge (чтобы объединить коммиты из разных веток).
14:28 Но что если я полностью хочу удалить старый коммит?
Чтобы удалить коммит так чтобы он не остался в истории, то можно сделать интерактивный rebase, и в редакторе vim на нужно коммите написать drop. Не благодарите)
благодарить за то что люди будут гуглить "как выйти из vim"???
Месье знает толк в изв...
@@barbossa7170 ахахахха, мдааа уж. Вот это вайтишники мощные пошли… как из вима выйти не разберутся, бедолаги
Коммент в поддержку канала. Спасибо, Влад.
очень хорошее видео, до этого знал, эти команды, но ты объяснил более глубже
Я щитаю надо было 12 делать:
merge и cherry-pick - тоже весьма важные команды, особенно если у сеньора пунктик - "1 ветка, 1 коммит", а иначе кровь из глаз у него идет. (из личной практики)
upd. туда же squash
Rebase и merge, немного отличаютьмя! А когда фигню закомитил то нужно знать про reset -hard
Поправьте, если не прав, но чтобы добиться поведения описанного в разделе git rebase в видео надо проделать следующие шаги:
1. git checkout feature (переходим в ветку feature, чтобы на 2 шаге сделать так чтобы первый коммит этой ветки оказался от последнего коммита ветки main/master)
2. git rebase main (переносим первый коммит наш, как будто мы сделали его от последнего актуального коммита в ветке main (предварительно ветку main надо подобновить, я обычно делаю git fetch и потом git rebase origin/dev, примерно такую конструкцию). Здесь ещё стоит уточнить, что если есть конфликты, то их придётся решить для каждого коммита в ветке feature (где затрагиваются эти изменения), а для новичка это, возможно, вызовет много проблем). А также важно то, что хеш наших коммитов в feature ветке изменится, и если над feature работаем не только мы, это может быть очень плохо, так что делайте rebase-ы только если один работали над feature
3. git checkout main (переходим на main)
4. git rebase feature (не делал ни разу, но в теории должно произойти поведение описанное в видео)
В целом мы на работе используем rebase, чтобы сохранить «красивый» git graph прямо перед созданием мердж реквестов, и так более структурно понятно кто какие изменения внёс и остаётся возможность откатиться на один коммит, если такое требуется
соглашусь, это и есть правильный подход использования rebase
@fakng-engineer
Я не поняла, почему делаем git rebase main, но после git fetch уже не main, а git rebase origin/dev ?
@@lidiagodo7622
Пункт с main - это из ролика (пошаговое объяснение того, что нужно сделать, чтобы добиться поведения с видео )
А в скобочках я там просто хотел показать как обычно происходит этот процесс в работе, мы в main впринципе льём изменения только через UI удаленного репозитория, поэтому чаще всего rebase (у меня лично в работе) выглядит как сочетание этих двух команд (git fetch и git rebase origin/dev)
@@Cleavesss Ооо поняла, большое спасибо!
Отличное изложение, спасибо. В какое программе сделаны анимации?
Друг, говоришь о rebase нужно явно рассказать почему используешь в "своей ветке" ибо это важный нюанс о котором ни слова. Тут 15 мин об основных коммандах явно мало времени для обьяснения.
Красава очень хорошо объясняешь. можно анимации на 20% меньше. и тебе меньше работы и нам голову не забиваешь
только что сообразил, что оказывается что я работаю фулстэк (js-react-vue + php) более7 лет.
а как же chery pick?
Я люблю Влада, Влада я люблю!
Стрижка топ
Влад, а в каком гите лучше работать? Десктопным или в консоли?
Я бы еще выделил git reset, а именно возвращение к предыдущему коммиту: git reset --hard HEAD
а где git merge?
Почему не упоминал merge ? В чем преимущество rebase?
Неправильное понимание гит ребейза. Он нужен для другого. Гит ребейз от мастера иногда делается перед отправкой локальной ветки на влитие в мастер, если у тебя по задаче было много коммитов, а хочется, чтоб они не перемешались с чужими коммитами, которые уже есть в мастере (влились одной кучкой, по порядку). Мы делаем git fetch && git rebase origin/master, гит подтягивает все недостающие коммиты из мастера, а твои личные коммиты переносит в конец истории. Иногда это сопровождается разрешением конфликтов, если правки чужих коммитов связаны с теми же частями кода, что в твоих. После этого можно пушить свою ветку и отдавать её на заливку в мастер.
Если не требуется такой перенос своих коммитов в конец истории, то можно делать git pull origin/master или git merge origin/master перед пушем.
Шпаргалки по Git нет (((
Кто-нибудь знает, почему аккаунт в гитхаб блокируется сразу после его создания?😢
Владислав, а в какой проге такие крутые анимации делаешь? Малой хочет тоже научиться такие делать и на информатике блестать.
канва)
Что с голосом?
Не работает ссылка на шпаргалку :-(
а в чём разница между ребейс и мёрдж?
Я ценю ваш труд и полезность видео, но белые вспышки с щелчком не нужны 😊
Забыл написать, четкая прическа
Давай уже, перелазь с французской "Р" на русскую.
13:46 и не прощает😂
Привет. На чем делаешь анимации?
canva
А как же git checkout -b ?
Это, конечно, все полезно, но....Зачем) Уже давно все делается прямо в IDE без заигрываний вручную с терминалом
В данном видео вместо rebase уместнее было бы merge.
Где шпаргалка, по ссылке не выдает?
После регистрации по ссылке , тебя перебросит в закрытый телеграм канал, в закрепе ждет шпаргалка)
А гит мердж?
В чем разница мерджа и ребэйз
merge твою ветку не переносит а просто сливает в месте последнего коммита. Rebase же переносит место (по сути первый а не последний твой коммит) где ты отколол свою ветку в указанное тобой место.
это сын премьер министра нашего?
6:37
Longtao на всех чтоли подписался в git?
УДАЛЯЙ! Я с этим позавчера весь день (10 часов) возился, а тут 15 минут. Так нечесно :(
Лайкос
Это нормально использовать ребейз в командной разработке? А потом удивляться фингалу под глазом от других разработчиков? Ты сделал ребейз и отменил все наработки своего коллеги. Потом коллега тебе дал по мордесам, выдал ручку и тетрадку которую ты должен заполнить фразой "При командной разработке я делаю мерж а не ребейз" и так 1000 раз чтоб запомнил.
Сделали ошибку, которую пытаетесь скрыть? Имейте в виду: Гит ничего не забывает! 😈
А что за компания? Хахах в каждом видео в начале «…в лучшей компании…»