git rebase --interactive (reword) оставил мне два дерева с одинаковыми сообщениями о коммите

Question

Я хотел перефразировать мои сообщения коммита. я использовал git rebase --interactiveи использовал reword изменить фиксацию сообщений. Я ожидал, что мое дерево останется таким же, но с разными сообщениями о коммите. Вместо этого я получил 2 дерева, одно из которых содержало исходные сообщения, одно перефразированное.

Я отредактировал дерево ниже, чтобы убрать сложность, поэтому, возможно, это не совсем точное представление о том, где что-то пошло не так и почему, но это четкое представление о том, что у меня есть сейчас. Обратите внимание, что есть 4 сообщения, которые по сути одинаковы, но слегка перефразированы. Уверяю вас, дельты одинаковы.

* 56bb877 (HEAD, bjyGuardProvider) BjyRuleAdapter:  checkpoint!  (same as 0e1f985)
* 6b765f1 Base:  Added a new FedcoUser local module (same as 47e1cf9)
* bbfb764 Base:  Added Zend Studio/Server deployment descriptor files (same as 6b7cc21)
* 8ee08b9 General:  Added vendor modules (no configuration applied) (same as 4648e11)
| * 0e1f985 (origin/bjy, bjy) Checkpoint:  BjyAuthorize works
| * 47e1cf9 Added a new FedcoUser local module
| * 6b7cc21 Added Zend Studio/Server deployment descriptor files
| * 4648e11 Added vendor modules (no configuration applied)
|/
* e539e7a Initial ZendSkeletonApplication

Как это исправить?

Если это абсолютно поможет, я могу поместить ссылку на полное дерево или предоставить любую другую информацию.

Answer 1

На самом деле это нормальное последствие перебазирования, которое не изменяет существующие коммиты, а добавляет новые. У вас было это:

A - B - C - D - E   <-- origin/bjy, bjy, HEAD=bjyGuardProvider

где совершать A это Initial ZendSkeletonApplication один, B является Added vendor modules, и так далее.

Вы тогда сделали git rebase -i коммитов B через E, в то время как HEAD говорил Git, что текущая ветка bjyGuardProvider, Ребаз скопирован B через E (следовательно, те же деревья) для новых коммитов с новыми идентификаторами коммитов и созданной меткой ветки bjyGuardProvider указать на конец новой цепочки:

A - B - C - D - E   [the old tip commit]
  \
    B'- C'- D'- E'  <-- HEAD=bjyGuardProvider

Но он не будет (и не должен) перемещать любые другие метки веток... так bjy а также origin/bjy оставаться привязанным к совершению Eпо старой цепочке.

Если вы двигаете свой собственный bjy подписать (вручную) и принудительно нажать это в репозиторий git на origin, вы можете (в зависимости от того, насколько разрешительным origin это) быть в состоянии переместить все три метки, чтобы указать совершить E', Старая цепочка больше не будет иметь меток и будет иметь право на сборку мусора, если это действительно единственные три метки, которые использовались для обозначения этих коммитов.

Если какой-то третий репозиторий имеет копию origin однако в репозитории они по- прежнему будут иметь старые ярлыки и старые коммиты, и вам нужно будет также заставить их перемещать свои ярлыки. Как отметил @poke в комментарии, поэтому не рекомендуется перебазировать опубликованные коммиты. ("Должен" и "не должен", в конечном счете, являются ценностными суждениями - является ли болью синхронизации всех других репозиториев, оправдывающей выгоду, какой бы она ни была? - но боль такая, как вы теперь видели).

Answer 2

Вы делали некоторые pull или же fetch а также merge после этого? Дерево выглядит так.

Переписав свою историю с git rebase имена (hashes) первого коммита и все последующие коммиты будут изменены, что приведет к git push потерпеть неудачу --force не указано

pullПосле этого новые коммиты будут заново вводить все коммиты, которые должны быть изменены.

Чтобы исправить свою ветку вы можете rebase снова сделайте forced push и не забывайте никогда не переписывать pushЭд снова разветвляется!