我是如何调试几乎所有涉及长期修改历史的问题的，用Git来跟踪，发现你在代码中引入了一个错误.
有时我们在项目上工作了很长很长的时间。我们可能会精心制作一个完美的1.0版本，然后向公众发布，我们开始进行bug修复，然后我们收到功能请求，我们努力改进应用程序。
在这个过程中的某个时刻，你会得到一个回归错误：一个意外的问题，是由代码中一个不相关的变化引起的。
有些东西不能像预期那样工作，尽管你最近并没有真正改变那部分代码。
或者是你碰过一个文件或函数很多次，以至于你不记得什么变化可能导致了向你报告的问题。
在任何情况下，首先要做的是确定错误在哪里。
如果你使用像Git这样的版本控制系统工作，事情就容易多了。你可以回到过去，找出引入该变化的确切提交。当你在团队中工作时，这一点很重要，因为其他一些人可能也在做这个工作，如果他们造成了错误，你可能不知道该怎么做--除了要求他们修复它，因为Git会给你这些信息。
一种方法是手动检查一些特定的提交。例如你可以从检查昨天的代码库版本是否正常开始。
我使用GitHub Desktop，它是GitHub推出的很棒的Git客户端。它很适合日常使用，但它不能让我签出单个提交。其他一些客户端可以，但你可以使用命令行。
运行
git checkout <COMMIT_SHA>
其中<COMMIT_SHA>是你想回滚的提交。它看起来会像5a06d3ca5e7adb6e67 。
如果你仍然有问题，你可以尝试用前一天的另一个提交进行同样的操作，以此类推，直到你找到一个代码可以工作的提交。
现在你需要运用分而治之的原则，在你最后一次尝试（没有成功）的提交和成功的提交之间选择一个提交。
重复这个过程，将每次提交的时间间隔减半，直到你确定引入问题的那个提交。
这是一件非常常见和有用的事情，所以 Git 引入了bisect 命令来自动完成这个过程。
从你的最新提交开始。使用git checkout your-branch-name ，例如git checkout master ，如果你已经检查出一个较早的提交。
然后运行。
还没有发生什么。你需要告诉Git一个坏的提交参考，即代码不工作的地方。
和一个好的提交，即代码工作了。
git bisect good 7f4d976e7540e28c6b0
Git开始了这个过程。
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[d18ebf1c7db9a9b44e8facc5ddb3551e641a64e2] fixes #25
看，在HEAD和我提到的好的提交之间，你有6个提交。Git告诉我还有两个步骤，直到我们找到有问题的提交。
我去测试代码，然后告诉 Git 结果：git bisect bad 或git bisect good ，取决于成功与否。
重复上述步骤直到找到坏的提交，然后运行git bisect reset 回到 HEAD 提交。
Git 会指导你进行这个分叉的操作。你可以输入提交的 SHA
