VS>> git-rebase - Reapply commits on top of another base tip VS>> Hе, я точно не хочу такую хрень. Где-то в гите перемудрили. AK> это не в гите, это в мозгах его пользователей и разработчиков такой AK> таракан.
AK> Вкратце: "твоя история нам нах.й не нужна! Засунь ее себе в жопу!" AK> "Мы желаем видеть правки как будто ты их делал поверх самой нашей AK> наираспоследней версии. Твоя история нам нах.й не нужна, ты понял?!"
AK> Поэтому есть механизм, переносящий все твои патчи поверх самой AK> распоследней версии в удаленном репо. (с возможностью тебе руками их AK> каждый раз изменять под эту версию, поскольку, разумеется, само AK> нихрена не перенесется)
И в смысле при rebase еще и конфликты обязательно вылезут, и надо будет их руками разрешать?
VS>> По-твоему это понятно звучит? AK> это вполне понятно - если бы ты понимал, для чего вообще нужен rebase.
Для извращений, как я понял. IMHO историю нельзя трогать, потому что это блин история.
AK> Тебе он, вероятнее всего - не нужен, тебе нужен эпизодический merge и AK> своя история на фоне этих мержей (включая и не ограничиваясь "а вот AK> тут пришлось отказаться от своих улучшений, потому что апстрим все AK> окончательно переломал")
VS>> А нельзя просто мержить из мастера в свою ветку, без rebase и VS>> прочих модификаций истории? AK> можно. Просто потом ты не сможешь вернуть эти изменения автоматически.
Не понял, что значит "вернуть изменения автоматически".
И как всё-таки лучше, коммитить в мастер и стягивать в него же, или стягивать в мастер, а свои изменения делать в своей ветке и сливать в неё из мастера? Какие плюсы-минусы у обоих подходов?
