9.2 Git - Перемещение коммитов - Rebase и merge: сравнение подходов

Поделиться
HTML-код
  • Опубликовано: 21 дек 2024

Комментарии •

  • @JavaScriptru-videos
    @JavaScriptru-videos  3 года назад +2

    Ссылки:
    - Git курс (playlist): ruclips.net/video/W4hoc24K93E/видео.html
    - Git разное (playlist): ruclips.net/video/8HxTHPkdedA/видео.html
    - Учебник и курсы по JavaScript и смежных технологиям: learn.javascript.ru

  • @bennails3447
    @bennails3447 2 года назад +15

    Это лучший курс по GIT, который я нашел на трёх языках: русском, английском и испанском. Спасибо!

  • @young_ceaser
    @young_ceaser 2 года назад +7

    Автор. Долгих лет тебе жизни

  • @Manhengest
    @Manhengest 3 года назад +8

    Спасибо за труды!

  • @Леонид-с5з
    @Леонид-с5з 2 года назад +2

    недостатки merge перед rebase
    1:09 пример
    2:58 пример на графической утилите sourcetree
    3:24 ограничения и недостатки rebase
    4:05 общее правило использования rebase
    4:30 вторая проблема rebase
    6:05 более экзотические ситуации
    6:58 насколько эта проблема критична и что делать, чтобы облегчить себе жизнь
    7:29 автоматизированные тесты
    7:39 rebase -x
    9:16 где еще полезна команда rebase

  • @RainbowJet1
    @RainbowJet1 2 года назад

    Отличное видео, всё понятно, спасибо!

  • @andreipalii1220
    @andreipalii1220 2 года назад +1

    9:16 - так а разве перенос коммитов через cherry-pick нельзя решить? (обойдя риски rebase). Или мб если таких коммитов много - то будет сложно передавать столько хэшов cherry-pick-у...

  • @АлисаФортунова
    @АлисаФортунова Год назад

    Спасибо за урок

  • @fahrenheit1863
    @fahrenheit1863 4 месяца назад

    Я только начал вникать в гит и у меня возникла ситуация которую я не смог понять, есть ветка develop и fix_bag от develop, в ветке develop бы один коммит, а в fix_bag 7, я выполнил rebase fix_bag исправил все конфликты, и затем решил выполнить merge fix_bag в develop и к моему удивлению пришлось разрешать те-же конфликты второй раз.
    После этого ветки fix_bag и develop все равно указывали на разные коммиты.

    • @fahrenheit1863
      @fahrenheit1863 4 месяца назад

      Или для ветки develop нужно тоже было делать rebase только уже на fix_bag?

  • @a.o.yaroslavov
    @a.o.yaroslavov 2 года назад +1

    Сколько ни пытался привыкнуть к rebase, понял, что merge безопаснее, хоть и сложнее.

    • @Das.Kleine.Krokodil
      @Das.Kleine.Krokodil 2 года назад

      на работе?
      а остальные коллеги что используют?

    • @a.o.yaroslavov
      @a.o.yaroslavov 2 года назад +1

      @@Das.Kleine.Krokodil Кому как нравится. Но ребэйз пару раз приводил к серьёзным проблемам, если ветку совместно использовали

    • @romabulava899
      @romabulava899 2 года назад

      @@a.o.yaroslavov а почему нельзя было создать еще веток к этой ветке?

  • @olgavasileva2521
    @olgavasileva2521 2 года назад

    👍👍👍

  • @Макс523
    @Макс523 2 года назад

    OK!

  • @yoshimitsu7723
    @yoshimitsu7723 9 месяцев назад

    зачем это все нужно, когда текущую ветку можно актуализировать с помощью git pull master?

    • @yersainaldabayev8836
      @yersainaldabayev8836 8 месяцев назад

      Ну ты сделаешь пулл, у тебя будет актуальная ветка. Пока будешь работать, параллельно кто то мерджнет свою ветку в мастер и опа и у тебя уже не актуальная ветка

    • @yoshimitsu7723
      @yoshimitsu7723 8 месяцев назад

      @@yersainaldabayev8836 а что мешает сделать пул перед пул реквестом?

  • @timurkash
    @timurkash 3 года назад +3

    Gitflow вообще запрещает rebase

    • @DrSkyholle
      @DrSkyholle 2 года назад

      С чего бы вдруг?