Подробная причина, почему удаленный git rebase такой злой

Поэтому я пришел из централизованного VCS и пытаюсь закрепить наш рабочий процесс в Git (новая компания, молодая кодовая база). Один вопрос, на который я не могу найти простой, но подробный ответ, заключается в том, что именно делает ребаз в удаленной ветке. Я понимаю, что переписывает историю, и в целом должны быть ограничены только местные филиалы.

Рабочий процесс, который я сейчас пытаюсь проверить, включает в себя ветку удаленного сотрудничества, каждый разработчик "владеет" одним из них с целью совместного использования кода. (При наличии 2 разработчиков и максимум 3 в обозримом будущем ветвь функций для каждого проекта и запроса функций кажется чрезмерной и требует больше затрат, чем полученная выгода.)

Потом наткнулсяэтот ответ и попробовал его, и он выполнил то, что я хотел - разработчик совершает коммиты и толкает их в свою собственную ветвь коллаба, когда он знает, что разрешено выпускать для постановки, он может удаленно перебазировать (раздавить и, возможно, реорганизовать), прежде чем слиться с разработкой ,

Введите исходный вопрос - если удаленная ветвь предназначена для совместной работы, кто-то другой должен ее рано или поздно вытащить. Если проблема в процессе / обучении заключается в том, чтобы не приглашать «гостевого разработчика» к этой ветке коллаборации, что на самом деле происходит с владельцем ветки, который перебазирует эту удаленную ветку?

Ответы на вопрос(2)

Ваш ответ на вопрос