Git 合并和修复带有两个分支的混合空格和制表符 [英] Git Merge and Fixing Mixed Spaces and Tabs with two Branches

问题描述

我经历了一些类似的 SOQ，但没有看到针对这种情况的适当解决方案.

我注意到在许多文件中，用于缩进的制表符和空格混杂在一起.我们遵循的编码标准目前使用 4 个空格作为制表符.

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

从反应的角度来看，是否有更好的解决方案?

这主要是技术领导、代码检查、代码审查问题，但我目前不在那个位置或案例.我可以轻松解决这个问题吗?(不幸的是，让违规者处理合并是不可能的！)

解决方案

默认情况下，git 会将行缩进中的每个差异视为更改，因此是的，您可能会在进行股票合并时遇到大量冲突.

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

git merge -s recursive -Xignore-space-change

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

<块引用>

• 如果他们的版本只在一行中引入空格更改，则使用我们的版本；
• 如果我们的版本引入了空白更改，但他们的版本包含实质性更改，则使用他们的版本；
• 否则，合并以通常的方式进行

在使用 diff 和一些额外选项进行合并之前，谨慎地查看 git 认为发生了什么变化.查看diff docs，看起来这些选项最能帮助您:><块引用>

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

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

I've gone through some similar SOQ's and have not seen an adequate solution for this case.

I've noticed that in many files there is a dirty mix of tabs and spaces used for indenting. The coding standard we follow uses 4 spaces for a tab currently.

Although this should have been addressed when it happened, I need to consider it now and would like to fix the files I come across. The issue is that there are two teams using different branches of code and we will eventually have to merge those branches. What will happen if we change all the files of our branch to be the correct formatting and try to merge it? Will it end up being difficult to do so? Will it show me a ton of conflicts? Ideally id like git merge to ignore whitespace but I dont know how it would know which version to choose.

Are there better solutions from a reactive point of a view?

This is primarily a tech leadership, code lint, code review issue, yet I am not in that position or case currently. Can I fix this easily? (Having the offenders handle the merge is out of the question unfortunately!)

解决方案

By default git will see each difference in a line's indentation as a change, so yes you're likely to end up with mass conflicts doing a stock merge.

However you can choose the merge strategy to use with the -s option:

git merge -s recursive -Xignore-space-change

This command would use the recursive strategy and uses it's ignore-space-change option. The git-merge docs explain quite well how this will affect your merge:

• If their version only introduces whitespace changes to a line, our version is used;
• If our version introduces whitespace changes but their version includes a substantial change, their version is used;
• Otherwise, the merge proceeds in the usual way

It would also be prudent to look at what git thinks has changed before doing the merge using diff with some extra options. Looking through the diff docs it looks like these options would help you out the most:

-b
--ignore-space-change Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.

-w
--ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.

这篇关于Git 合并和修复带有两个分支的混合空格和制表符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！