Git 合并并修复具有两个分支的混合空间和选项卡
我已经经历了一些类似的 SOQ，但没有找到适合这种情况的适当解决方案。
我注意到在许多文件中，用于缩进的制表符和空格混杂在一起。目前我们遵循的编码标准使用 4 个空格作为制表符。
虽然这个问题应该在发生时就得到解决，但我现在需要考虑它，并希望修复我遇到的文件。问题是有两个团队使用不同的代码分支，我们最终必须合并这些分支。如果我们将分支的所有文件更改为正确的格式并尝试合并它会发生什么？这样做到最后会不会很困难？它会向我展示大量冲突吗？理想情况下 id 像 git merge 一样忽略空格，但我不知道它如何知道选择哪个版本。
从反应的角度来看，是否有更好的解决方案？
这主要是一个技术领导力、代码检查、代码审查问题，但我目前不处于那个位置或情况。我可以轻松解决这个问题吗？ （不幸的是，让违法者处理合并是不可能的！）
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!)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
默认情况下，git 会将行缩进中的每个差异视为更改，因此，是的，在进行库存合并时，您可能最终会出现大规模冲突。
但是，您可以选择与
-s选项一起使用的合并策略：此命令将使用递归策略并使用其
ignore-space-change选项。 git-merge docs 很好地解释了这将如何影响您的合并：。在使用 diff 和一些额外选项进行合并之前，谨慎地查看 git 认为发生了什么变化也是明智的。浏览 diff 文档 看起来这些选项对您最有帮助：
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
-soption:This command would use the recursive strategy and uses it's
ignore-space-changeoption. The git-merge docs explain quite well how this will affect your merge: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:
为什么不在两个分支上通过 indent 运行两个代码库并使用相同的样式？不需要很长时间。
这样您就不会遇到任何空格或其他问题（例如不同的块样式）。否则，是的，将很难合并这些分支。
显然，假设您用 C 编写代码。
Why not run both code bases through indent with a the same style on both branches? Doesn't take long.
Then you won't have any whitespace or other issues (like different block styles). Otherwise, yes, it will be hard to merge those branches.
Assuming you code in C, obviously.
假设您至少有三个分支（例如“master”、“team1”、“team2”），然后使用所有正确的间距/缩进更新“master”分支，并让每个团队从“master”中提取更改。然后，每个团队应确保其所有新代码/文件符合您的标准编码实践。
Assuming you have at least three branches (say 'master', 'team1', 'team2') then update the 'master' branch with all of the correct spacing/indenting and have each team pull in the changes from 'master'. Each team should then ensure all of their new code/files meet your standard coding practice.
请注意，如“Git：合并时没有空格冲突”中提到的，使用
git merge -Xignore-space- Change将pre-commit钩子 合并策略可以帮助完全删除那些尾随空格。Note that, as mentioned in "Git: Merging without whitespace conflicts", using
git merge -Xignore-space-changewillpre-commithook in addition of that merge strategy can help remove completely those trailing whitespaces.