Git合并并修复带有两个分支的混合空格和制表符

Question

我已经完成了一些类似的SOQ，并没有找到适合这种情况的解决方案。

我注意到在许多文件中都存在用于缩进的标签和空格的混合。我们遵循的编码标准目前使用4个空格作为标签。

虽然这应该在发生时解决，但我现在需要考虑它并想修复我遇到的文件。问题是有两个团队使用不同的代码分支，我们最终必须合并这些分支。如果我们将分支的所有文件更改为正确的格式并尝试合并它会发生什么？最终会难以这样做吗？它会告诉我很多冲突吗？理想情况下，像git merge一样忽略空格，但我不知道如何知道选择哪个版本。

从反应的观点来看，是否有更好的解决方案？

这主要是技术领导，代码lint，代码审查问题，但我目前不在那个职位或案例中。我能轻易解决这个问题吗？ （不幸的是，违法者处理合并是不可能的！）

Answer 1

默认情况下，git会将行缩进中的每个差异视为一个更改，所以是的，你很可能最终会发生群体冲突进行股票合并。

但是，您可以选择要与-s选项一起使用的合并策略：

git merge -s recursive -Xignore-space-change

此命令将使用递归策略并使用它的ignore-space-change选项。 git-merge docs很好地解释了这将如何影响你的合并：

  

  
• 如果他们的版本只引入了对行的空格更改，则使用我们的版本;
  
• 如果我们的版本引入了空格更改，但其版本包含重大更改，则使用其版本;
  
• 否则，合并以通常的方式进行
  

在使用带有一些额外选项的diff进行合并之前，看看git认为已经改变了什么也是谨慎的。通过diff docs看起来这些选项可以帮助您最多：

  

-b
   - 忽略空间变化   忽略空格量的变化。这会忽略行尾的空格，并认为一个或多个空格字符的所有其他序列都是等效的。

     

-w
   - 忽略所有的空间   比较线条时忽略空格。这会忽略差异，即使一行有空格而另一行没有。

Answer 2

为什么不通过indent在两个分支上以相同的样式运行两个代码库？不用花很长时间。

然后你将不会有任何空格或其他问题（如不同的块样式）。否则，是的，很难合并这些分支。

假设您使用C编码，显然。

Answer 3

假设你至少有三个分支（比如'master'，'team1'，'team2'），那么用所有正确的间距/缩进更新'master'分支，让每个团队从'master'中获取更改”。然后，每个团队应确保所有新代码/文件符合您的标准编码实践。

Answer 4

请注意，正如＆＃34; Git: Merging without whitespace conflicts＆＃34;中所述，使用git merge -Xignore-space-change将

• 忽略文件中的所有空格更改，而不仅仅是存在冲突的空白
• 但是，生成的合并文件会返回空格，
• 使用pre-commit钩子以及该合并策略可以帮助完全删除那些尾随空格。