Git合并和修复混合空间和两个分支的选项卡 [英] Git Merge and Fixing Mixed Spaces and Tabs with two Branches

查看:200
本文介绍了Git合并和修复混合空间和两个分支的选项卡的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述



我注意到,在许多文件中,有一个混淆的组合用于缩进的制表符和空格。我们所遵循的编码标准目前使用4个空格作为制表符。



尽管在发生这种情况时应该解决这个问题,但我现在需要考虑它,并且希望修复我遇到的文件。问题是有两个团队使用不同的代码分支,我们最终必须合并这些分支。如果我们将分支的所有文件更改为正确格式并尝试合并,会发生什么?它会最终难以做到吗?它会让我看到很多冲突吗?



从视图的反应点有更好的解决方案吗?

p>

这主要是一项技术领导,code lint,代码审查问题,但我目前并不处于这种情况。我能否轻松解决这个问题? (不幸的是,让罪犯处理合并不成问题!)

解决方案

默认情况下,git会在行缩进作为一种改变,所以是的,你很可能最终会发生大规模冲突进行股票合并。



然而,您可以选择合并策略与 -s 选项:

  git合并-s递归-Xignore-space-change 

该命令将使用递归策略并使用它的 ignore-space-change 选项。 git-merge 文档很好地解释了这会如何影响您的合并:
$ b



  • 如果他们的版本只对一行引入空格更改,则使用我们的版本;

  • 如果我们的版本引入了空白变化,但其版本包含实质性更改,则会使用其版本;

在使用diff与一些额外选项进行合并之前,仔细看看git认为发生了什么变化。仔细查看差异文档,看起来这些选项最能帮助您:


-b

--ignore-space-change
忽略空白量的变化。这会忽略行尾的空格,并认为一个或多个空格字符的所有其他序列是等效的。



-w

--ignore-全空间
比较行时忽略空格。即使一行有空白,而另一行没有空白,这也会忽略差异。



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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆