Ссылки: - Git курс (playlist): ruclips.net/video/W4hoc24K93E/видео.html - Git разное (playlist): ruclips.net/video/8HxTHPkdedA/видео.html - Учебник и курсы по JavaScript и смежных технологиям: learn.javascript.ru
Просто как боженька промолвил. Я потратил на самостоятельное изучение rebase около двух дней, но только 8 минут этого видео меня посвятили о хоть какой-то идее процесса, а ведь это только начало ^^"
2:16 3:44 отлчичие git rebase --abort от git reset --hard и git reset --quit 4:43 git rebase --skip (все изменения из текущего коммита будут проигнорированы и rebase пойдет дальше копировать следующие) 4:53 пустые коммиты - коммиты, которые не привносят никаких изменений, например если кто-то в основной ветке их уже внес (rebase пропускает их автоматически) 5:15 продолжение перебазирования через индексирование и git rebase --continue 6:04 отмена rebase через перенесение указателя обратно 6:24 rebase (как и merge и reset) создает файл-ссылку ORIG_HEAD с идентификатором того, откуда была перенесена ветка 6:32 следовательно, чтобы перенести ветку обратно можно указать git reset --hard ORIG_HEAD 6:38 минусы такого подхода (git reset --hard ORIG_HEAD), вместо этого в более сл. ситуациях можно использовать более надежный вариант: git reflog [ветка (лучше чем HEAD)] -1 (- 1 по желанию) 7:22 git show --quiet [ветка]@{1} 7:28 git reset --hard [ветка]@{1} 7:46 Аргументы rebase - можно указать вместо одной ветки (на которую переносится текущая) две (первый аргумент - ветка, на которую переносится, второй - с которой), но чтобы не запутаться в последовательности аргументов, лучше использовать две отдельные команды - git checkout [ветка] + git rebase [ветка, на которую хотим перенести]
А я правильно понимаю что есть указатель HEAD который как бы показывает где мы сейчас находимся (какую версию проекта видим), и именно он на 2:38 передвигается. НО, есть также и другой указатель HEAD - который указывает на последний коммит каждой из веток (т.е каждая ветка имеет свой HEAD)? на 5:37 он передвигается
UPDATE: все примерно как я и написал выше, только второй тип обычно называют head (маленькими буквами), и хранятся эти head для каждой ветки в ./git/refs/heads/... А ещё есть другой тип ref-ов, те которые указывают на теги. Ну а HEAD это тоже ref, только специальный тип (о нём можно думать как о глобальной переменной)
Не понятно, что значит "старые коммиты A, B и C со временем будут удалены". Когда делаю rebase. у меня остаются как A, B, C, так и A', B', C', никуда старые коммиты не удаляются.
Ссылки:
- Git курс (playlist): ruclips.net/video/W4hoc24K93E/видео.html
- Git разное (playlist): ruclips.net/video/8HxTHPkdedA/видео.html
- Учебник и курсы по JavaScript и смежных технологиям: learn.javascript.ru
Наконец то, нашлось видео как решать конфликты при rebase, вообще об этом никто не говорит в ютубе. Однозначно лайк
сколько искал, пока это не посмотрел, ничего понять не мог, замечательное объяснение, огромное спасибо !
Просто как боженька промолвил. Я потратил на самостоятельное изучение rebase около двух дней, но только 8 минут этого видео меня посвятили о хоть какой-то идее процесса, а ведь это только начало ^^"
Спасибо, более подробной и понятной информации ещё не находил. Наконец-то я понял, как это работает)
Спасибо! Все никак не мог понять почему при ребейзе просит решить конфликт с какимто древним коммитом . Тут все предельно ясно описано
спасибо огромнейшее, очень полезно и доступно
2:16
3:44 отлчичие git rebase --abort от git reset --hard и git reset --quit
4:43 git rebase --skip (все изменения из текущего коммита будут проигнорированы и rebase пойдет дальше копировать следующие)
4:53 пустые коммиты - коммиты, которые не привносят никаких изменений, например если кто-то в основной ветке их уже внес (rebase пропускает их автоматически)
5:15 продолжение перебазирования через индексирование и git rebase --continue
6:04 отмена rebase через перенесение указателя обратно
6:24 rebase (как и merge и reset) создает файл-ссылку ORIG_HEAD с идентификатором того, откуда была перенесена ветка
6:32 следовательно, чтобы перенести ветку обратно можно указать git reset --hard ORIG_HEAD
6:38 минусы такого подхода (git reset --hard ORIG_HEAD), вместо этого в более сл. ситуациях можно использовать более надежный вариант:
git reflog [ветка (лучше чем HEAD)] -1 (- 1 по желанию)
7:22 git show --quiet [ветка]@{1}
7:28 git reset --hard [ветка]@{1}
7:46 Аргументы rebase - можно указать вместо одной ветки (на которую переносится текущая) две (первый аргумент - ветка, на которую переносится, второй - с которой), но чтобы не запутаться в последовательности аргументов, лучше использовать две отдельные команды - git checkout [ветка] + git rebase [ветка, на которую хотим перенести]
Ааха, хотів витерти з екрану волосся, а то ваша аватарка)
5:24 Разрешение конфликта
Спасибо за урок
Шикарное видео!
Большое спасибо
Илья, спасибо!!
я понял
спасибо, дорогой)
Спасибо за крайне полезное видео. Все предельно разжевано!
Один вопрос. Что означает флаг -i после команды rebase ?
Спасибо большое!
OK!
А я правильно понимаю что есть указатель HEAD который как бы показывает где мы сейчас находимся (какую версию проекта видим), и именно он на 2:38 передвигается.
НО, есть также и другой указатель HEAD - который указывает на последний коммит каждой из веток (т.е каждая ветка имеет свой HEAD)? на 5:37 он передвигается
UPDATE: все примерно как я и написал выше, только второй тип обычно называют head (маленькими буквами), и хранятся эти head для каждой ветки в ./git/refs/heads/...
А ещё есть другой тип ref-ов, те которые указывают на теги.
Ну а HEAD это тоже ref, только специальный тип (о нём можно думать как о глобальной переменной)
Не понятно, что значит "старые коммиты A, B и C со временем будут удалены". Когда делаю rebase. у меня остаются как A, B, C, так и A', B', C', никуда старые коммиты не удаляются.
Из видео, понял что это команда лучше не пользоваться :)
5:24 Разрешение конфликта
тяжело