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