网易视频云技术分享：记一次.gitignore的操作细节
网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PAAS服务，在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。现在，网易视频云的技术专家给大家分享一则技术文：记一次.gitignore的操作细节。
“作为一个刚上路的新手司机，git操作当然要远离各种炫酷的git GUI，因为这些GUI容易使你忽略git本身的工作流程，走向万劫不复的深渊。”
---- 一位上路多年的老司机对我说
这个事情发生的背景是这样的，在我们的专题发布系统工程里面，本地开发的css文件采用scss实时watch编译方式，最终发布到线上时，也会重新压缩合并css文件，一直以来都没有什么问题。但是随着开发人员的增多，代码提交频次的增加，以及每个人的编辑器环境不同，会导致编译出的css文件有些许的不同，比如有人watch出的css文件里面会有charset声明：@charset "UTF-8";这些文件的更改都被提交上来了。这个时候当我去拉代码时，每次都会出现不少的conflict，我必须停下来，更改scss文件，重新watch一次，才能把我的修改提交。时间一长，工作的效率就降低了。
好了，有问题就解决呗，我考虑到scss文件本来在代码发布的时候会被编译成css文件，也会有相应的压缩合并等，那把css文件和css目录ignore不就好了吗？开发的时候，自己watch，发布的时候，依赖自动化工具脚本执行一系列watch更新打包操作，肯定不会有什么问题。于是，我轻车熟路的打开了.gitignore文件,啪啪啪，增加了css/忽略规则，commit提交。
这个时候有css文件修改，git status 看一下，
咦，肿么css文件还是 Changes not staged for commit ，难道我gitignore正则表达式写错了？
查了一些，好像没问题啊。好，google一下：
原来是我误解了 .gitignore 文件的使用方法， .gitignore只能作用于 Untracked Files，也就是没有被 Git 记录过的文件，或者说没有add和commit相关操作的文件。
这里就能解释我的规则不生效的原因是css目录下的文件都存在了git操作记录，此刻再加入到 .gitignore 就无效了。解决这个问题，我们可以这样做：
- 删除git对于该文件的追踪信息；
# -r 递归删除文件夹里内容 git rm -r --cached <path>
- 更新 .gitignore，把对应的规则写入 .gitignore
- add＋commit + push。
好了，试一下，
commit，push代码
这时候如果有css文件的修改，我们git status试下
奇怪了，这个怎么回事呢，对css文件的追踪也删除了，gitignore也更新了，也推送到远端分支了，可是还不对。
看一下.gitignore
发现，对于css目录的忽略已经存在于.gitignore中了，我们的更新没有生效。
好了，先把.gitignore中css/忽略规则删掉，提交代码。
重新执行上面的 1->2->3 步
再次修改css文件，好了，搞定！
PS:关于.gitignore无效还有另外一种解决方案，但是这个方案是有后遗症的，不推荐。
就是我可以设置:
git update-index --assume-unchanged <PATH>
让git忽略我本地需要排除的文件，提交到远程分支后，这样git就不会把这些修改提交到版本库了。
那么，这个方案有什么问题呢？
设置update-index这种 exclude 的方式针对的是 Git 数据库里被记录的文件，换句话说 .git/info/exclude 目录里是你自己本地需要排除的文件，而不是远程库里那些真正需要忽略的文件，这样的设置不会提交到版本库，也不会影响他人。反观我们的.gitignore 这个文件本身会提交到版本库中去。
问题就来了，如果想要达到真正忽略这些文件的提交，必须团队里面每个人都去设置git update-index --assume-unchanged <PATH>才有效。
如果这个时候有新人进来或者更换电脑，从库里拉完最新的代码，没有执行git update-index --assume-unchanged <PATH>，直接提交，这时git又开始记录该文件的变化了。所以我们不推荐这种处理方式。
----------------------------------------------------------------我是分割线-------------------------------------------------------------
解决了上面的问题，下面根据自己入职以来老司机对我的尊尊教诲，以及我们技术组里面的要求，总结下git使用方面的一些奇技淫巧和好的习惯：
1.每次提交代码前，仔细查看更改。
代码提交谨慎些，操作前可以使用git status、 git diff，看看有没有误改文件，或者有没有debugger、alert等调试代码提交。根据经验，很多时候，小手一抖，就提交了一些莫名其妙的修改，这个排查起来很费时费力。
2.pull和push最好带上分支名。
同时push.default请修改为simple方式。当我们把git升级后，会看下如下提示：
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
我们可以看到，Git 2.x 默认的是 simple，而 Git 1.x 默认的是 matching，就是说在没有指定分支的前提下，Git 2.x默认处理当前分支，Git 1.x则将所有你本地的分支push到远程仓库中对应匹配的分支。这是一件很危险的事情，尤其当master分支出现权限控制异常时。我们这边出现过master分支权限控制的问题，有同事把master分支的误操作提交上去了，后果可想而知。谨慎起见，先修改push.default，然后pull和push带上远程分支名。
3.配置git alias，可以节省不少git操作时间
git config --global alias.st status # git操作频次较高的命令大概有一下几个：
[alias]
st = status
ci = commit
co = checkout
br = branch
4.关于git rebase
为了保证git提交树的干净，避免出现眼花缭乱的merge操作记录，建议使用git rebase进行替换。
5.优化git commit的提交日志
git commit时尽量不要只是简单的 update，dev，bugfix等，因为这些标记确实不利于后续的问题定位查找。我们开发小组已经硬性规定，谁再提交这样简单的commit标记，要请吃水果，貌似有不少同学中招了~
总之对于git工具的使用，还是需要慢慢摸索，不断实践的。当大家使用熟练后，再配合git GUI也是没问题的。最后，希望这篇文章能对大家有用，各位有什么好的git操作建议，欢迎交流~