Риск использования git Interactive ReBase для ТОЛЬКО изменения имени автора в наборе коммитов?

Question

В моей организации у нас есть хук коммитов, который отклоняет коммиты, если ЛЮБОЙ коммит в дереве имеет значение автора, которое не соответствует определенному шаблону.Обычно это используется для отлова ошибочных коммитов до их слияния с целевой веткой.Тот факт, что он также сканирует существующие коммиты в целевой ветви, обычно не имеет значения, так как хук предотвращает объединение этих «испорченных» коммитов.

Однако у людей, которые поддерживают этот хук, вчера возникла производственная проблема.в результате все разработчики были заблокированы.Таким образом, они отключили его, пока не смогли выяснить, почему он ломался.

Я сразу же был обеспокоен этим, потому что это означало, что возможно, что разработчик, который не уделял должного внимания, мог объединить один илиmore фиксирует неверное авторское значение.

Как я и ожидал, моя проблема была реализована, поскольку одному разработчику это удалось.

У нас есть досадный обходной путь, который может заставить ловушку пройти проверкудаже при наличии некоторых «испорченных» коммитов в целевой ветви (требует создания исходной ветви в центральном репозитории (BitBucket) вместо локального репо), но я действительно не хочу этого делать или иметь вседругие разработчики делают это.

Я действительно хочу просто исправить уже объединенные коммиты.

Итак, это означает интерактивное перебазирование.Я понимаю процесс, даже как изменить значение автора для каждого коммита.Меня беспокоит предупреждение о «переписывании истории» и о том, может ли это что-нибудь сломатьИнтерактивная перебазировка хороша, когда вы работаете с веткой запросов на извлечение, которая используется только вами, и еще не объединена с целевой веткой.Я говорю о том, чтобы сделать это на «master».

Однако ЕДИНСТВЕННОЕ изменение, которое я собираюсь внести в любой из этих коммитов, является значением автора.Если это единственное изменение, которое я делаю, какие есть риски?Устраняет ли это основной риск «переписывания истории»?

Answer 1

Когда вы переписываете свою историю коммитов и заставляете ее удаленно выступать в качестве центрального репо, эта операция не меняет ссылки, которые другие люди, которые в данный момент используют этот репо, сохранили в своих локальных копиях. .

Что это значит с точки зрения последствий?

Возможно, они разветвляли свои собственные ветки функций (с работой над ним) от старой ссылки из master, которая больше не существует в переписанной истории. На этом этапе отметим, что вся история после самого старого переписанного коммита сама будет переписана, так как при создании хеша используется ссылка его родителя, поэтому даже если вы измените только one commit, вся история переписывается с этого коммита до самого последнего коммита.

Так что они не смогут ничего отправить на пульт, который больше не распознает их версии истории репо. (также, остерегайтесь взлома тегов и подписанных коммитов, спасибо phd за напоминание)

Чтобы исправить это, им нужно будет сделать резервную копию своих текущих веток, восстановить локальные версии master до новой версии, а затем перебазировать / выбрать свою работу поверх нее.

Итак, командное общение является ключевым здесь . Если кто-то не знает о процессе и (... поскольку ему отказывают, когда он пытается подтолкнуть ...) насильно толкает своего старого рефери в какой-то момент процесса ... ну, вы получаете (страшная) картина. Соберите каждого пользователя вокруг обсуждения по этому вопросу, и когда все согласятся с тем же курсом действий, это станет решаемым случаем.

(Чтобы выйти за рамки этих общих принципов, взгляните на ответ Торека здесь , который очень информативен по этому вопросу.)