公司改用Git做版本控制之后，从SVN转到Git之后有一点不适应，出现了好几次代码混乱或丢失的情况，对工作造成了一些影响，但也在解决问题的过程中汲取了一些经验。现在对Git渐渐熟悉，大范围代码混乱的情况已经再没出现过，至此回头做个总结：
1, 先添加，再提交。
在一个新建文件的完整的提交流程里，Git需要先add（将新文件提交到暂存区），然后commit（将变更添加到历史记录，并赋予本次提交一串名称）。以下是我们常用的Netbeans工具下Git的工作流。
更多在Netbeans中Git的使用在：https://netbeans.org/kb/docs/ide/git_zh_CN.html
但在Netbeans使用Git的时候我并没有执行add这一步，似乎即便是直接commit，它就会把新文件也一起提交上去，或许是这个工具比较人性化。但我知道这个步骤之后，还是比较注意新文件的提交，每次新创建了文件之后都会来一句add，后来还专门写了一个脚本，把add和commit写在一起，这样就万无一失了。
2, 关于重定基址。
在之前用Netbeans的时候出现代码混乱问题，就是因为重定基址……和还原。我借了本书来看，重定基址也叫分支变基，命令是git rebase。举个例子：公司服务器上有Git版本，那就叫服务器G，其他员工分别为A，B，C，D，大家都兢兢业业地敲代码，然后和G进行对比，pull或push。有一天，A员工用了rebase，于是A员工电脑上的代码取代了G，成了主支，原本的服务器G成了分支。造成的影响是，整个项目的代码以A员工的为准，BCD三人若想提交，必须和A的代码做比对。
后果也并不是不可挽回的，但如果A员工的代码碰巧Bug比较多，那其他员工合并的时候就需要解决很多冲突了。
因此，我个人的经验是，除非是特殊情况，否则尽量不要rebase。
3, 关于还原
还原，顾名思义就是还原，命令行是git checkout，还原其实没什么不对，但是在Netbeans里，执行重定基址后，就会给出三个选项——还原，合并，取消。无数次经验告诉我，在这样的情况下点击合并是99%不成功的，这里说的99%是因为我不否定有成功的情况，但我还没遇见过。
这个时候，只要点击还原，就鬼使神差地不会报错，看上去似乎一切正常。
然后……五分钟之后，同事提交之后会发现TA的代码被改动了。
假设：所有人的代码都是一天只提交一次，由于我——不，由于A员工的代码在今天经过rebase成了主干，整个项目的代码以A的为准，并且A还checkout过一次，版本成了昨天。
A提交后，BCD也开始陆续提交，过程中很自然地有冲突，但直接合并似乎不行，于是BCD三个人也像A一样，rebase=>checkout，于是灾难降临了，所有人都把代码还原了一次，看到的全都是上一版本的代码。
我记得最重大的一次代码事故就是这样酿成的……
由于这次事故得到的教训是：不能为了解决冲突而还原代码。要斟酌！要三思！
为了更好地熟悉Git，我开始用改用命令行做Git提交，出现冲突的时候多数也是到源文件里修改。当然同一文件中出现多处冲突时还会借助Netbeans工具，毕竟可视化的高亮背景比
=========
>>>>>>>>>>>>>>>>86t67tf76r6578g7t75456rt7sxy8
这样的东西要显眼。
最近的问题，由于和同事间的开发工具的配置路径和参数的不同，导致提交代码时，将配置文件一并提交上去后，其他人的开发环境受影响，暂时的解决方法是：用不厌其烦的手动修改还原解决。
试过配置.gitignore文件，但不管用。
准备采用的解决方法：重新安装自己的开发工具，把各种参数路径设置得和同事一样。
更高明一点的解决方法：得到同事的建议，虽然不能完全忽略某个文件，但可以只提交某些文件，于是修改命令行下的自动提交脚本，只提交某几个日常会改动的文件夹，配置文件自然就排除在外了，脚本仅多了两行，却能一劳永逸！亲测两天，没有出现问题！
相比较之下，好像还是命令行提交更灵活一点……