Git 与 JSON 文件冲突答案

【问题标题】：Git conflicts with JSON filesGit 与 JSON 文件冲突
【发布时间】：2016-01-12 08:17:59
【问题描述】：

我们的网站使用一堆带有翻译的 JSON 文件进行本地化（每种语言一个文件）。文件内容如下所示：

{
    "Password": "Passwort",
    "Tables": "Tische"
}

许多团队成员同时编辑这些 JSON 文件，添加新短语并编辑现有短语，即使人们更改不同的行，我们也会遇到很多冲突。

有没有办法以有助于避免合并冲突的方式设置 git？

附：我发现这个脚本可以帮助本地合并：https://gist.github.com/jphaas/ad7823b3469aac112a52。但是，我对能够为团队中的每个人解决问题的解决方案感兴趣（即使是通过 GitHub 的网络界面编辑 JSON 的人）。

【问题讨论】：

Here 是一篇可能有帮助的文章。
嗯，如果您所有的开发人员都在不同的时间、不同的行位置、不同的内容修改这些文件，我看不出有什么方法可以避免冲突。处理合并冲突只是使用分布式异步工作流的一部分。我认为你可以 100% 避免它的唯一方法是让每个开发人员在他们自己修改文件之前等待其他开发人员完成修改文件......但这违背了使用 分布式的全部目的> 像 Git 一样的 VCS。
好的，所以经过我的思考，避免合并冲突的最有效的方法是让您的开发人员在进行并提交之前非常频繁地与上游更改同步自己的本地更改。但听起来这不是您的团队正在做的事情，特别是如果他们直接通过 GitHub 进行更改。您可以让他们在彼此之间更频繁地发出拉取请求，但是如果您所做的只是一次提交一行更改，那么这开始变得非常麻烦，更不用说用大量复杂的合并提交污染您的提交历史了。
如果您想保持更清晰的历史记录（没有合并提交），您的团队需要养成使用自己本地计算机上的上游更改重新定位本地更改的习惯。据我所知，GitHub 界面不允许你做 rebase，只有经典的 merging。
这可能会有所帮助：stackoverflow.com/questions/5587626/git-merging-within-a-line 在我看来（正如 NikoNyrh 也怀疑的那样）git 无法像您想要的那样精细地识别块边界。 git-diff 有 --word-diff 选项，在合并之前/之后会很有帮助。一种选择是使用外部工具进行合并，例如wiggle 建议 unix.stackexchange.com/questions/20021/…

标签： json git github localization git-merge

【解决方案1】：

您看到如此多冲突的另一个原因可能是您的开发人员使用了不同的行尾配置。请参阅 Git 中的 How to change line-ending settings。为了找出答案，您可以使用 Hex 编辑器打开一个 json 文件，查看整个文件的所有行结尾是否一致。

【讨论】：

【解决方案2】：

你可以运行git pull --rebase。这样，当其他人编辑了您的 JSON 文件时，git 将首先提取他们的更改，然后尝试将您的更改应用到他们的之上。每次都有一个选项可以这样做：只需将您的分支名称替换为 BRANCH 并运行：git config branch.BRANCH.rebase true

【讨论】：

【解决方案3】：

即使人们的变化不同，我们也会遇到很多冲突线条

这不应该是这样，如果同一行被不同的人修改，提交然后合并，你只会发生冲突。

哦，我真的试过了，遇到了一些奇怪的问题。

提交 1（主）：

{
    "a": "1",
    "b": "2",
    "c": "3",
    "d": "4",
    "e": "5",
    "f": "6",
    "g": "7"
}

提交 2 (tmp)

{
    "A": "1",
    "B": "2",
    "C": "3",
    "d": "4",
    "e": "5",
    "f": "6",
    "g": "7"
}

提交 3（主）：

{
    "a": "1",
    "b": "2",
    "c": "3",
    "d": "4",
    "E": "5",
    "F": "6",
    "G": "7"
}

git merge tmp: 正确结果

{
    "A": "1",
    "B": "2",
    "C": "3",
    "d": "4",
    "E": "5",
    "F": "6",
    "G": "7"
}

但是，如果行 "d" 也被修改，我会遇到冲突，也许 git 无法建立差异边界。为了避免这种愚蠢的 git 行为，我的愚蠢建议是在 JSON 文件中添加“填充”（丑陋，不是吗？但不再有冲突）：

{
    "a": "1",

    "b": "2",

    "c": "3",

    "d": "4",

    "e": "5",

    "f": "6",

    "g": "7"
}

【讨论】：

有趣！我们应该试试看！我会让你知道它是否对我们有用。谢谢！
我能够重现与您的测试用例的冲突，并且用换行符填充确实可以解决它！感谢您实际尝试并找到易于实施的解决方案！

【解决方案4】：

在这种情况下我会做的一件事是在数据库表而不是 JSON 文件中维护配置 - 如果它们经常更改。正如其他人已经指出的那样，如果您一直在对配置进行大量更改，那么您就无法避免冲突。无论如何，您的示例看起来更像是英语单词和其他语言之间的映射，因此三列表就足够了。

如果需要，可以每次即时生成 JSON 文件，也可以在部署期间从数据库表中为每个服务器生成一次。

【讨论】：

这将是一个不错的解决方案，没想到！谢谢！
@katspaugh 乐于助人:)

【解决方案5】：

例如，有 2 个开发人员（开发人员 A 和 B）在一个项目中工作。我将创建 2 个翻译文件：A.json 和 B.json。 A.json 用于开发人员 A，B.json 用于开发人员 B。我将创建名为 en_US.json 的翻译文件。 en_US.json 在 .gitignore 文件中被忽略。

所以翻译目录的结构如下：

$ tree . -a
.
├── A.json
├── B.json
├── en_US.json
└── .gitignore

所以现在，我必须创建一个任务来将所有 JSON 文件合并到 en_US.json。如果您正在运行 Javascript 项目，则更容易。我建议你使用grunt 或gulp 来运行任务。比如可以参考https://www.npmjs.com/package/grunt-merge-json或者https://www.npmjs.com/package/grunt-concat-json

【讨论】：

如果A 和B 添加相同的键怎么办？
它属于您在任务中定义的脚本