Git学习除了推荐官方网站:https://git-scm.com/之外，

我个人比较推荐初学者或者被动使用者可以学习参考廖雪峰的这个教程:https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/00137402760310626208b4f695940a49e5348b689d095fc000

推荐官方教程的理由是最权威最详细，推荐廖雪峰教程的原因是可以帮助初学者或者是英语不是特别好的朋友们深入浅出的学习。

不过我个人还是比较推崇官网。当然了，廖雪峰前辈的Git教程也很不错，我记得当初在校学习的时候，参考的就是他的教程。

让我不仅想起了，没有Git，也没有SVN的日子，动态web项目，和同学们一起手动来合并代码，事实证明这样效率低且出问题率高。我最先接触的版本控制还是Git,Git给我的感觉是用起来还是挺爽的。比如只要电脑在手，在哪都可以开发。而SVN就不能了。虽然说，SVN也有其代码托管，不过我还是喜欢Git。

Git和SVN及其很久之前的CVS存在什么区别，和Git的基础使用大家可以参考廖雪峰的教程。我就不再赘述。

今天我重新温习了下廖雪峰的Git教程，发现虽然开发有很长时间了，但是我对Git只仅仅局限在那么几个简单使用和简单命令而已。关于Git的代码审核和其他诸多功能我还是不太了解。当然了，自开发以来遇到的大大小小问题，发现了一个很重要的原因就是原理不懂。当使用比较熟练时，同时也看了一些相关的书籍，参考了一些朋友们写的博文，深受感触，自那后，出的问题也很少了。我想这就是收获，解决了问题，并知道了原理。

比如，今天一位同事在使用git的时候，由于忽略了git它本身存在一个叫暂存区的概念，导致代码无法提交。

git有工作区和暂存区，看的见的叫工作区，看不见的叫暂存区。

git add .相当于将文件提交到暂存区，git commit -m ‘test’ 相当于提交到本地仓库，最后通过git push -u origin master提交到主分支上。

当然这里还有一点要强调的是，开发者们应该有自己的开发分支，主分支一般情况下都不能动，一般动的情况是，比如像我公司每周项目出一个版本，相当于礼拜一到礼拜五的5点前，一直都在自己的分支上开发，最后合并到开发者的主分支，通常叫devp分支，最后才合并到master分支。

不过事实上，我们并没有这么做，导致的问题是，如果我们团队某个人不细心的话，比如，一般提交代码，要么是新增功能，或解决Bug，或优化某个模块等等。通常提交代码，自己并没有仔细测试，直接提交上来，导致最后，测试人员说，这么明显的bug，你们居然没有发现。那真的是有种打脸的感觉。

暂不说面子上过不去，面子事小，成本事大，就是因为没有仔细测试，导致代码出Bug，为了解决这个Bug又得拉代码开工干，其实如果在提交前仔细测试是可以避免的，自开发以来，我发现很多情况，就是因为我们软件开发者们的“懒惰”导致许多不必要的Bug。我自己当初也是如此，就是现在而言，也会犯一些错误，犯错有其自身要素，还有其制度原因。如果建立良好的代码审核制度，我觉得应该可以提高代码质量，虽说之前我写了关于Sonar的使用博文，Sonar是一款代码质量检测工具，有助于提高代码质量，但是并不具有强制性作用。关键还是自觉。但是人的自觉性，是会变的，受环境影响。制度才是王道。

这篇文章给我很大的启发，希望意识到这个问题的朋友们都可以看看:

https://www.cnblogs.com/wenhx/p/How-We-Code-Review.html

接下来我将尝试在公司推进代码审核制度，不过在此我觉得还是有必要仔细研究一下，写一个可行性方案，这样于上级领导，于团队成员都有个交代。