尽管我试图避免它，但我必须维护三个master等效的分支，每个分支都有微小的变化。我已经阅读git和使用它几年了，所以我熟悉以下传统智慧：
merge除非有意义，否则不要这样做。改为使用rebase。cherry-pick是您的朋友。pull --rebase在遥控器上。rebase.他们没有告诉你的是，传统智慧会创建一堆几乎相同的提交，除了会更改其 SHA1 的小细节。为什么这很重要？它违背了用git log --left-right --graph --cherry-pick --oneline branch1..branch2and比较分支的目的git show-branch，这尤其令人讨厌。感觉就像是在滥用廉价分支。这使得几乎不可能看到每个分支中缺少哪些补丁。
那么，如何使多个分支与相同的 SHA1 保持一致，以便可以使用这些工具呢？补丁是最好的方法吗？
您不能在多个位置保留具有相同 SHA 的提交，因为提交的“位置”（其在历史记录中的位置）由 SHA 标识。
Git 提交包含某些数据，其中包括当前 repo 状态的快照、当前时间和日期、提交者名称和电子邮件，以及父提交的 SHA。
这意味着当您将提交放在其他地方（rebase, cherry-pick, patch+apply）或更改其时间（commit --amend）时，SHA 会有所不同。
这是 Git 的一个重要特性（Git 历史就是所谓的Merkle 树）。
正如您所注意到的，您可以使用我上面提到的各种历史重写命令来维护（内容）等效提交。
根据您的情况，您可能可以使用其中的提交而master无需复制它们。如果那些使你的“ master-equivalent”分支不同的更改纯粹是附加的（即它们发生在提交中，这些提交总是可以附加到 master 中的最新提交），那么你总是可以将你的其他分支重新定位master并感到高兴，因为那时它们只是master按原样包含所有's 提交。
另一方面，如果您的更改属于需要在历史早期插入的类型（即，master 必须在您区分更改之后附加新的提交），那么您将无法保持这样的“好”历史.
第二种情况我不能自发想到一个例子，但是理论上是可以的（不管是内容实际需要，还是项目规范等外部因素需要）。
我认为除非有意义，否则不合并不是传统智慧。如果您希望保留具有相同 SHA1 哈希的历史记录，请合并并避免挑选。