这么多年一直没有太在意代码文件 tab/空格， UTF/GBK ， UNIX/DOS 换行符 的问题，这几天被 Git 坑的不浅，需要统一处理一下并以后固定下来， 大家都怎么设定的呢？

统一处理还不是分分钟的事？

@avastms 不想自己的习惯设定和别人差异太大，所以想了解下比较流行的做法

UTF-8 without BOM
LF Line Ending
Spaces for indentation

一般都是按楼上的这么做：
1、文件一律 UTF-8
2、代码一律用空格缩进，这样不管在什么编辑器下看起来效果都一样
3、使用 Unix 换行符
除非项目有自己的代码风格

你自己不规范还说Git坑你... 编码也没注意, 没处理过中文显示之类的问题么?

UTF-8, Unix换行, Python空格缩进, 其它全Tab缩进(但是不用行中Tab对齐).

Tab缩进就是8个空格的长度, 自定义导致出问题的人或者编辑器都是异端异端异端! (笑

是你在坑git

在Windows下面用GIT管理C#的项目，其实还是有很多的坑。。
我遇到过的几个小坑说一下，希望有朋友遇到过并且解决了：
1.换行符，使用GIT的format-patch功能打上补丁之后，VS会提示换行符混合，需要处理成Win的换行符
2.对于资源文件，比如添加了图片的resx，git做merge的时候基本上不可能成功合并。。
3.winform相关的界面改动，会导致designer文件变动，由于这个文件是根据控件的顺序变化的，导致merge十分麻烦，如果是两个人改一个界面的话真的是蛋疼（这里需要考虑分工的问题）
4.中文支持，这个的话主要是VS不能设置所有文件的默认保存编码为UTF-8，中文乱码，但是影响不大，只是在做format-patch的时候基本上有中文注释的编码就会应用失败。但是使用cherry-pick就没问题。
想到再补充吧。。。希望有小伙伴解决啦

@kingme 用vs开发，就用vs自带的版本管理呗…应该支持的好一些吧。

一定要UTF-8 without BOM！！！

@tairan2006 TFS 的分支你懂得。。。。习惯了GIT的分支之后。。。。。。

@kingme
vs 保存的文件默认 utf-8 with bom
所以我随手写了个简单的 python 脚本用来去 bom、改换行符 CRLF 到 LF
顺便去掉行尾空白，并给 EOF 加个换行符
Designer.cs 这种硬伤就只能放弃治疗了

在源代码里 UTF8/GBK 或者 BOM 或者 Line Break 出问题的，都不能算是合格程序员。
在缩进和对齐上，tab用来缩进，空格用来对齐是国际惯例，包括 Python 。这样在所有的编辑器，不管是 4 空格缩进，还是 8 空格缩进，看起来都是正常的。

国际惯例不是 utf8 / 4空格 / 无bom / unix换行符 么

utf8无BOM
4空格 callback多的语言2空格
换行LF

@typcn 上次看linus还谁说喜欢8空格..

在windows,ubuntu下同时使用vim, gvim, git的我表示，坑很多

团队分布于wins osx 和ubuntu的情况下，坑确实不少

0.禁用AutoCRLF。
1. indent必须使用U+0009，alignment必须使用U+0020，禁止混用表示单一用途。没为什么，这就是这些字符的原意。如果文本编辑器显示会抽风/没法配置，那说明的编辑器太残了。
2. 除了特定的脚本（依赖shebang/Windows批处理）或者准备到处cat的东西，都使用UTF-8+BOM。
UTF-8尽管空间效率不一定就高，但是兼容性良好。如果是其它编码，至少也得用基于UCS的。GBK首先的问题就是没法涵盖某些字符，换GB18030经常又不如UTF-16。UTF-8的另外一个好处是字节序统一，没有纠结LE和BE的必要。
没有BOM的东西充其量只是可能随处中断不完整的byte sequence，是不是就配叫regular file呢，值得怀疑。
3.只要使用的实现支持CR的情况就CR+LF。大多数实用的编辑器同时支持两者，有些支持检查不当的混用。注意有些协议要求CR+LF。而违反CR+LF导致的错误比违反LF通常更容易检查。
Reference: https://bitbucket.org/FrankHB/yslib/wiki/WikiRules.en-US.md

@FrankHB 既然“UTF-8字节序统一”，那还要 byte order mark 作甚。

要我说这东西压根就不应该有选择。

@dorentus 我看到的LZ说的“统一”修饰的是“处理”，于是理解为有“一致”的规约。所以我给出了我正在使用的整套方案。仔细看你还会注意到，里面已经对不同形式和目的的内容给出例外了，并非都使用UTF-8+BOM。
不过，一开始没特别注意到后来回复的“不想自己的习惯设定和别人差异太大”，那么我得承认这不太符合LZ的要求。不过关于这点我希望能被理解：这里没有谁强调尽量减小差异就是最终目的。
和你看样子理解的一样，加了BOM之后，剩下的东西和BOM不一样了，在这个意义上不“统一”。但这是有意的。上面已经解释过大概，这里再补充一点理由。
类比解释就好像一些媒体文件的封装格式，有效“负载”内容不同于全部文件内容，通常典型地还有附加的元数据。BOM对于文本文件来说就是附加在文件头的元数据。作为持久储存的形式，元数据的存在即在一定意义上表明维护者注意到了文件的完整性及其对内容的限定。而例外则是考虑到使用形式（用于拼接）或者储存之外更主要的目的（作为脚本执行）的实际限制来设定的。

@williamx 虽然可以理解，但很可惜历史已经如此，你无法改变你之外的整个世界，只能改变自己了。
题主可没说他的的代码就是要用在哪的，这样就没法推定用啥了。
同样是文本表示的数据，IEEE Std 1003.1规定text mode只管LF，RFC 2616规定一些分隔符就得要CR+LF。编码就更不用说了。一定能确定哪个比哪个更应该遵守而打死也不选择么。
缩进硬要用空格嘛……也行，祝不要被某些markdown坑。
所以在没有更具体的限定之前，所谓“固定下来”只能是策略而不是只用某一种形式。