在日常开发和项目管理过程中往往不可避免地存在很多痛点。如果能及时发现和解决掉这些问题，可以极大提高开发我们的开发效率和减轻项目的技术债务，减少项目风险。很多减轻技术债务的工具都是预防性的。比如编译器，lint，静态分析工具等。这些工具都通过防止开发人员签入代码码，这一方面限制了开发人员的自由，引起不适，而且可能会导致一些潜在的问题。而且尽管通过管制和审核流程似乎应该是完美无瑕的代码，但是实际上并不一定会带来功能良好的系统。
软件开发的过程不仅涉及开发人员之间以及开发人员与他人团队之间的交互，如何快速的无声的项目的痛点这是个问题。如果你的开发项目是采用git管理，那么Git本身就能给我们很多好用的工具，本文虫虫就给大家讲讲git中自带哪些解决痛点的工具。
git log 发现最常改变为文件
我们时常忽略一个事实是，我们经常修改的，修改最多的文往往是问题发生最多的，而这些文件往往就是开发和项目的痛点。我们要找到这些痛点，或者熟悉一个未知的项目不知道如何入手的时候，首先可以做的就是找出项目中改变最多，提交commit最频繁的文件。找出仓库最常变化的文件(top10)命令为：
- git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -rg | head -10
比如我们最开源安全项目OpenSSH查看一下top10变化文件：
我们可以看到除了，版本更新文档ChangeLog以外，变化第二的是configure.ac这个文件是项目编译文件makefile的配置文件。源码里面修改最多的是sshd.c是sshd服务器端的源代码文件。
可以看到这个命令很有用，但是很长不好记，怎么办?其实也好办，那就是加一个git别名即可。vim打开~/.gitconfig配置文件，在[Aliases]部分增加以下配置项：
- cctop10 = "!git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -rg | head -10"
这样，对一个仓库我们只需执行这样做是按照更改的数量对项目中的文件进行排序，并获取前10个文件。随着时间的推移，这些文件中发生的更改最多，因此，这些文件中需要更改的机会更大。
git blame 找出痛点的来源
在知道变化最多的文件这个痛点后，我们需要详细了解痛点过程。或者项目的另一个痛点是，发现项目文件被某人修改后就崩溃了，再也跑不起来了。想找出是谁修改的，大家来鄙视他，或者谴责(blame)它。这就需要一个git另一个利器blame，他就是告诉我们这个问题行(变化)是谁引入的。比如我们同样以openssh 项目为例，查看一下sshd.c的文件的变化历史
git blame sshd.c:
如上我们可以看到基本上每一行代码出现的现场，包括了commitID、提交人、详细时间和代码。
如果文件较大，可以通过"-L"参数指定开始和结束行，比如sshd.c文件的200行开始的20行内容的来源。
关于git blame 注意：
如果一个commitID前面有^号，那么自文件创建以来，对应的行就从没修改过。
blame也可以跟踪跨文件的行变化。比如对一个大文件代码重构或者配置文件被分散到多个小文件，那么会显示大文件中的原始提交和大文件的名称。可通过-C选项来实现。
git bisect 找到引入问题的commit
如果知道是哪个行代码，那次commit引入的问题，我们可以用blame揪出提交问题的人。但是如果不知道是哪儿引入的问题，需要找出引入问题的提交。则需要用一个git 工具bisect。它也很简单用二分发不断测试回溯到中间的commit点，直到找到这个问题引入点。
git bisect start [终点] [起点]
终点为你确保有问题的commit(如果不能确定那就是现在HEAD)，起点为你确保的之后才出现的问题(如果不确定就用最开始一次commits)。
执行这个命令后，项目仓库的文件状态会调到这两次的中间commit，这时候测试代码，如果项目运行OK，就执行git bisect good。如果还是报错，则执行git bisect bad。
执行后，git会根据good或者bad状态跳转到后半段commit的一半(即3/4)commit处，或者1/4 commit处
继续测试代码，标识good或者bad
以此类推直到找到引入问题commit。
总结：
git是一个天生为开发而生的工具，生来就是为了帮助我们解决痛点的。而且git中很多工具就是对应解决我们日常具体痛点的，善用他们不光可以让我日常生活更舒服，也能极大提高开发效率。"工欲善其事，必先利其器"，"磨刀不误砍柴工"希望我们会用并且善用这些工具。
