9.5 Git - Перемещение коммитов - Перебазирование слияний, --rebase-merges

[@JavaScriptru-videos]

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

[@УльвияКарахмазли]

Спасибо вам огромное, Илья! Очень выручили столь наглядным объяснением

[@АлисаФортунова]

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

[@Леонид-с5з]

2:01 --rebase-merges
2:39 rerere - разрешение повторных конфликтов

[@andreipalii1220]

Хмм, как-то не логично что при git rebase --rebase-merged конфликт может появится повторно, ведь изначальный коммит слияния *_УЖЕ_* включает в себя фикс конфликта.
Rebase копируя коммит слияния должен скопировать *_ВСЁ_* что входит в его diff, включая фикс конфликта. Разве нет?!
Было бы интересно узнать в чём логика, и где я что-то упускаю.

[@maks-rst]

Отвечаю не тебе, а скорее тем, кто на видео наткнется и будет задавать тот же самый вопрос (не тебе потому, что уже год прошел, вряд ли тебе этот вопрос спать не дает до сих пор), но не получит ответа. Достаточно посмотреть на результат ДО/ПОСЛЕ, до перемещения мы имеем: коммит слияния D, который был создан от коммита Y, тут при переносе не возникнит конфликтов, но конфликт возникнет из-за того, что до переноса у нас был коммит слияния C и B, теперь же у нас есть C^|, на который указывает вершина ветки master, соответственно, это уже другой код, который потенциально может привести к конфликтам и все сломать, поэтому вполне возможно, что конфликт придется решать второй раз, ведь у нас теперь вершины двух веток указывают на одну ветку, которую мы поставили на самое высокое место и оно весь код унаследовало

[@mirakmalsultanov3398]

вы сами хоть в реальных проектах использовали такие сложные команды? а то кажется это сложнее чем само программирование

[@Макс523]

OK!