我不知道这是否是一个常见问题。大多数情况下，我们从我们的开发回购协议中提取CSS文件，GIT与当前文件冲突，通过将“>>>”和“< <”标记置于顶部和底部完全合并这两个文件，以及一个“===”标记将它们分开。GIT上CSS文件中的连续合并冲突
我们尝试了一些不同的缩进方式，这有所帮助，但没有成功。我们没有任何其他文件类型的问题，在这种情况下，大多数是PHP和JS代码。
如果有帮助，我们已经将生产中的所有文本编辑器设置为使用CRLF。
感谢。
这通常是由于某种自动转换造成的。
你可以尝试和设置config autocrlf to false在你所有的git（dev和prod）？
这样，不执行自动转换，这有助于消除导致潜在合并冲突的问题？
你是否还有一些空白设置可以引入一些自动修改？注意：启动git 2.8+（2016年3月），合并标记将不再引入混合行结尾（如CRLF文件中的LF）。注意：启动git 2.8+（2016年3月），合并标记将不再引入混合行结尾（如CRLF文件中的LF）。
请参阅“Make Git use CRLF on its “<<<<<<< HEAD” merge lines”。
罪魁祸首就是CRLF ...如果某些框是窗口，那么自动CRLF转换将导致那些以“unix”格式存储文件的框，即使在您的情况下，unix（和mac）盒子以“dos”格式存储它们。
解决方案是要么告诉大家使用“unix”格式，这是git项目的典型定制 - 并且允许windows用户使用“dos”格式，因为git（特别是msysgit）会默认自动转换。
或继续使用CRLF（这里可能是更好的主意），并告诉Windows用户使用autocrlf甚至safecrlf停止。