.gitattributes合并策略不起作用 [英] .gitattributes merge strategy not working

问题描述

我在.gitattributes中使用合并策略来在合并期间保留文件。我也使用 git config --global merge.ours.driver true; 在我的配置中设置驱动程序（我检查了配置 [merge]我的合并策略设置正确：

$ b 我的合并策略设置正确：

  src / public / bundle.js合并=我们的
 src / public / main.min.css合并=我们的
服务器/中间件/ https_redirect .js merge = our 
  

然而，当我合并时，我仍然从合并的分支中获取文件。

我可能做错了什么？

解决方案

您需要的是自定义的合并策略

请参阅 git：如何添加自定义合并策略？（编辑以添加：编写合并策略处理程序比编写合并策略处理程序要困难得多编写一个自定义的合并驱动程序，但它是获得我想要的行为的唯一方法。）

你有一个自定义合并驱动程序

你的设置看起来是正确的（尽管有点欺骗，使用 / bin / true 或者等同于保留％A 文件并成功退出:-)）。但是我怀疑你遇到了通常的问题，即：

如果有两个，Git只调用一个三路合并驱动程序差异来合并。

也就是说，假设我们实际上正在进行三向合并。这意味着有一个文件的合并基础版本，例如 src / public / bundle.js ，因为合并基础提交不同于两个分支提示提交。我们在某个分支上，它的提示提交是 1111111 ，并且我们正在合并其他哈希ID 2222222 和 git merge-base 1111111 2222222 是 bbbbbbb 。因此，Git已经完成 git diff bbbbbbb 1111111 来从基础到我们的变化，并且 git diff bbbbbbb 2222222 得到从基础到他们的变化。

基础版本 src / public / bundle.js 提交 bbbbbbb 。但是，也许差异从 bbbbbbb：src / public / bundle.js 到 1111111：src / public / bundle.js 是空，而从 bbbbbbb：src / public / bundle.js 到 2222222：src / public / bundle.js 是非空的。

在这种情况下，Git em>执行文件的三路合并。它不需要，所以它不打扰。它永远不会调用您的自定义合并驱动程序;它只是抓住该文件的 2222222 版本，并说我完成了，全部合并！

无论你让Git使用自己的内置合并代码还是指定一个自定义驱动程序，它都是真实的：当它可以或者认为它可以离开时不会执行合并代码时，它永远不会调用合并代码一个合并。它只是需要一个改变版本，并称它为好。

（我个人认为这是错误的/一个错误，但Git多年来一直这样做，而Git人似乎并不倾向于改变它。）

I'm using a merge strategy in .gitattributes to preserve files during merges. I also used git config --global merge.ours.driver true; to set the driver in my config (I checked the config for [merge "ours"] driver = true and it is there).

My merge strategy is set correctly:

src/public/bundle.js merge=ours
src/public/main.min.css merge=ours
server/middlewares/https_redirect.js merge=ours

Yet when I merge, I am still getting the files from the branch being merged.

What could I be doing wrong?

解决方案

What you need is a custom "merge strategy"

See git: How do I add a custom merge strategy? (Edit to add: writing a merge strategy handler is much harder than writing a custom merge driver. But it's the only way to get the behavior I believe you want.)

What you have is a custom merge driver

Your setup does seem correct (albeit a bit "cheat-y", using /bin/true or the shell built in equivalent to just leave the %A file alone and exit successfully :-) ). But I suspect you're running afoul of the usual problem, which is:

Git only invokes a three-way merge driver if there are two diffs to combine.

That is, assume we're actually doing a three-way merge. This means there is a merge base version of some file, such as src/public/bundle.js, since there is a merge-base commit that differs from the two branch tip commits. We're on some branch, whose tip commit is 1111111, and we're merging some other commit whose hash ID is 2222222 and git merge-base 1111111 2222222 is bbbbbbb. Hence Git has done git diff bbbbbbb 1111111 to get the change from base to ours, and git diff bbbbbbb 2222222 to get the change from base to theirs.

The base version of src/public/bundle.js is the one in commit bbbbbbb. But, maybe the diff from bbbbbbb:src/public/bundle.js to 1111111:src/public/bundle.js is empty, while the diff from bbbbbbb:src/public/bundle.js to 2222222:src/public/bundle.js is non-empty.

In this case, Git doesn't do a three-way merge of the file. It doesn't have to, so it doesn't bother. It never invokes your custom merge driver at all; it just grabs the 2222222 version of the file and says "I'm done, all merged!"

This is true whether you let Git use its own built-in merge code, or specify a custom driver: it never bothers invoking the merge code at all when it can—or thinks it can—get away without doing a merge at all. It just takes the one changed version and calls it good.

(Personally, I think this is wrong / a bug, but Git has done it this way for many years, and the Git folks seem not inclined to change it.)

这篇关于.gitattributes合并策略不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！