Question

我正在与一个拥有大量JSON配置文件的项目的大型团队合作。它们经常变化，当然，还有很多合并冲突。我们的开发人员使用一堆不同的GUI合并工具来选择合并中使用的行。

我们的许多合并都是通过“选择两条线”来解决的（参见下面的示例）。在很多这些合并中，GUI合并工具似乎不知道他们需要添加逗号来使结果语法正确的JSON。我们的开发人员必须手动添加逗号，并且经常会忘记这样做（再次参见下面的示例）。

分支A

{
     "enabled": true,
     "apiUrl":"https://myapi.com/v1"
}

分支B

{
    "enabled": true,
    "clientID": "abc123123"
}

合并分支：

{
     "enabled": true,
     "apiUrl":"https://myapi.com/v1" <=== oops, no comma
     "clientID": "abc123123"
}

有没有办法格式化JSON以防止这种情况发生？我这样想（见下面 - 属性行之间的逗号）可能会解决问题，但我不确定。它似乎也浪费了很多空间。

{
     "enabled": true
     ,
     "apiUrl":"https://myapi.com/v1"
     ,
     "clientID": "abc123123"
}

除了告诉我们的员工在解决合并冲突时要更加小心，我还有什么选择。

Answer 1

不幸的是，这里的真正问题似乎是人为错误：）

要求你的员工要小心点＃34;在对代码进行更改时，这是一个好主意，但它可能在将来不会阻止此问题。我不认为有办法自动修复＆＃34;冲突，因为一旦JSON缺少一个逗号，它就不再是一个有效的JSON，也可能是一个普通的非结构化文本文件。考虑使JSON无效的可能性是实际错误，而不仅仅是错误地通过错误逗号进行合并。

我可以建议的一件事是实现一个"pre-commit" git hook来尝试JSON.parse（或类似的）文件，如果发生错误，你可以用适当的消息来阻止提交。 / p>

应该注意的是，实际上并没有阻止错误的发生 - 相反，您可以在保存有问题的更改之前检测到错误并通知用户。

Answer 2

对于它的价值，你提出的解决方案类似于用逗号开始非初始行的Haskell习语。

{
     "enabled": true
     ,"apiUrl":"https://myapi.com/v1"
     ,"clientID": "abc123123"
}

在这种情况下的好处是它似乎涵盖了多个开发人员追加新密钥的常见情况，使第一行保持不变。

有没有办法格式化JSON逗号，使合并GUI工具快乐？

2 个答案: