我已经经历了一些类似的 SOQ，但没有找到适合这种情况的适当解决方案。
我注意到在许多文件中，用于缩进的制表符和空格混杂在一起。目前我们遵循的编码标准使用 4 个空格作为制表符。
虽然这个问题应该在发生时就得到解决，但我现在需要考虑它，并希望修复我遇到的文件。问题是有两个团队使用不同的代码分支，我们最终必须合并这些分支。如果我们将分支的所有文件更改为正确的格式并尝试合并它会发生什么？这样做到最后会不会很困难？它会向我展示大量冲突吗？理想情况下 id 像 git merge 一样忽略空格，但我不知道它如何知道选择哪个版本。
从反应的角度来看，是否有更好的解决方案？
这主要是一个技术领导力、代码检查、代码审查问题，但我目前不处于那个位置或情况。我可以轻松解决这个问题吗？ （不幸的是，让违法者处理合并是不可能的！）
默认情况下，git 会将行缩进中的每个差异视为更改，因此，是的，在进行库存合并时，您可能最终会出现大规模冲突。
但是，您可以选择与以下命令一起使用的合并策略：-s option:
git merge -s recursive -Xignore-space-change
该命令将使用递归策略并使用它的ignore-space-change选项。 git 合并docs https://git-scm.com/docs/git-merge很好地解释这将如何影响您的合并：
- 如果他们的版本仅对一行引入空格更改，则使用我们的版本；
- 如果我们的版本引入了空白更改，但他们的版本包含实质性更改，则使用他们的版本；
- 否则，合并将以通常的方式进行
在使用 diff 和一些额外选项进行合并之前，最好先看看 git 认为发生了什么变化。纵观整个差异文档 http://git-scm.com/docs/git-diff看起来这些选项对您的帮助最大：
-b
--忽略空间变化
忽略空白量的变化。这会忽略行尾的空白，并认为一个或多个空白字符的所有其他序列是等效的。
-w
--忽略所有空格
比较行时忽略空格。即使一行有空格而另一行没有空格，这也会忽略差异。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
