Question

我参与了一个名为Secret M. Chronicles（SMC）的开源项目。

我们似乎遇到了一些git merges的问题：

我们在git中有两个主要分支：release-2.0（即将发布的版本）和devel（用于开发）
决定将所有源代码切换为K＆amp; R格式标准。
格式化适用于devel但不适用于release-2.0。其中一个团队成员表示格式化工具可以改变逻辑，即使它不应该，这对于release-2.0分支来说是不可接受的。
格式更改后，已将合理数量的更改推送到devel分支。
每次我们将release-2.0合并到devel中时，格式化更改会导致每一行显示为冲突，需要在合并期间仔细检查。这增加了犯错的可能性，更不用说乏味了。
我们已经讨论过从devel中删除现在的格式，以便在发布完成之前消除这些冲突，但这并不简单：
- 团队成员暗示恢复可能不足以防止合并冲突（如果我理解正确的话，基于git如何工作）以及需要从历史记录中完全删除
- 团队成员还表示，在版本2.0中添加K＆amp; R不会减少合并冲突，因为它会被认为是历史上的一个不同变化。
- 我们有更多的分支正在试用功能。来自devel的更改已合并到这些分支中。有些人也可能有来自github的分叉。有人担心历史编辑可能会导致其他分支/分支出现问题。

我真的不希望我们急于完成发布，以便在保持格式化的同时减少合并冲突，但我不希望我们通过在git中使用糟糕的历史编辑策略来导致更严重的问题。我们怎么解决这个问题？

公开查看

Answer 1

您可以尝试：

git merge -Xignore-all-space

另见：

就个人而言，我只想修复release-2.0上的格式。在发布之前解决这个问题要容易得多，然后在未来一个月或几年内有两种不同的源代码形式。如果您担心格式化工具会破坏内容，只需在重新格式化之前编译，然后检查二进制文件是否相同。