我正在 GitHub 上维护一个自定义版本的 Ghost 主题。它从主要的 TryGhost/Casper 存储库中定期接收更改流，这并不难跟踪。
有一件事情困扰着我，这与我主题中的 custom-*.hbs 文件有关。每当 Ghost 更新 post.hbs 时，我必须记住将这些更改也合并到每个 custom-*.hbs 模板中。
有没有办法告诉 Git post.hbs 的更改必须始终合并到我的多个文件中？
post.hbs -> post.hbs
post.hbs -> custom-blogger.hbs
page.hbs -> page.hbs
page.hbs -> custom-training.hbs
目前的 repo 可以在这里找到：
目前，我已诉诸于手动区分更改并将其应用于相关文件。
【问题讨论】：
简短的回答是no，有点可惜。
当 Git 进行真正的合并时——“作为动词合并”，我喜欢这样称呼它——Git 使用三个提交：合并基础，它是 Git 自己找到的，和两个提示提交。根据定义，其中一个提示提交始终是 HEAD，而另一个通常由某个分支名称标识：
o--o--X <-- you-are-here (HEAD)
/
...--o--* [merge base]
\
o--o--Y <-- other-branch
和往常一样，所有三个提交都是所有文件的快照。 Git 执行合并——结合自合并基础以来的不同更改——实际上是通过运行：
git diff --find-renames <hash-of-*> <hash-of-X> # what we changed
git diff --find-renames <hash-of-*> <hash-of-Y> # what they changed
Git 然后梳理这些差异——两个 diff 命令产生的变更集——并配对文件，以便它知道基础中的 file.ext 与 @ 是同一个文件987654325@ 在我们的和/或他们的。
如果重命名检测器检测到基础中的file.ext 在我们的提交X 中变为newname.ext，Git 知道它应该将他们对file.ext 所做的更改与我们对@987654330 所做的更改结合起来@-vs-file.ext，将最终结果存储在newname.ext中。但这是严格成对的。尽管git diff 支持多个“查找副本”选项，但git merge 没有“查找副本”选项。此外，没有“打破现有配对”选项（git diff 有一个，-B 有一个阈值，类似于-M 用于重命名查找和-C 用于复制查找）：如果合并基础和一个tip 包含一个路径为 P 的文件，该文件对在合并期间配对。如果合并基础和另一个提示包含路径为 P 的文件，则该文件对同样成对。
因此，如果您的合并基包含post.hbs并且两个提示都包含post.hbs，则严格的配对是post.hbs = post.hbs。
【讨论】：
简短回答：不。但是您可以使用git-merge-file 来实现这样的目的：
git merge-file <current-version> <common-ancestor> <other-version>
您可以使用第三个占位符文件创建一个“common-ancestor”，其中应包含合并前的主文件：
git show HEAD~1:post.hbs > parent-post.hbs
然后运行以下命令将进行 3 路合并：
git merge-file custom-post.hbs parent-post.hbs post.hbs
为了使其自动化，您需要创建一个post-merge githook，该post-merge githook 在重新创建common-ancestor 文件的常规合并之后运行，然后合并更改。
如果custom-* 文件与其非自定义对应文件相同，请考虑使用symlinks。
【讨论】：