关于学习的一些思考
有些操作也许永远都不会用，或者看到它的第一眼就觉得，这个用不上。
或者即使用得上也是做一些弱关联的工作，就是需要的时候就去解决，不需要就不去管它。
那天，我做完了升级某项功能的 API，代码提交了，并且通过了测试，代码在线上跑着，完全没有问题的样子。
而我觉得的问题，而是代码写的不太好的问题，恰好此时又不是下班时间，手中也
暂时没有其他什么事情，就准备 review 一下代码。
看着看着，觉得这里不好，那里冗余，想要精简一下，有时候突然发现，这一看就是 bug，改了改了。
为什么会有这种心理呢，我认真想了想，觉得，当时一边写代码，一遍调试，而当时，一旦出现bug，就在哪里补上一个几句代码，或者当时思维转的比较快，以至于我后面几乎没什么印象，或者看不懂当时为什么会这样做。
review 完成，改了好几个地方，并且这些地方看似都十分简单，根本不需要测试。而从表面看，确实不需要测试， 如我在父级函数删除了一个 filter，因为子级函数同样会过滤，等等。
时间过了一周，我再次接到任务，要去修改那项功能的某些API，我自然的从 dev 分支切换到了那个功能专属的分支，一顿操作后，提交代码，请求合并。
这时我发现，在 Gitlab 上面发现了几个陌生的修改，而且我也一时想不起来当时为什么要这样改（这些修改就是上次修改完没有测试，也没有合并的改动）, 还好，这些修改都比较简单，一看逻辑都懂(其实并没有关联上下文来看), 好了，直接合并吧。
合并后，我的新功能测试完全没有问题。过了一会，旧功能开始出现一些细微的问题， 于是我开始寻找，发现问题就是出现在我改动的那几个看似简单的代码上。
这里我认真反思：
- 做 review 需要认真去做(我觉得 review 坑还是挺多，一不小心就进去了)，修改了任何代码，最好进行测试一遍。
- 在 Git 使用方面，如果代码已经提交并且合并，接下来的修改如果合不合并都行，那么请不要做这个修改，或者做完修改后及早测试–合并，否则有一天你也许
会不认识它了，从而引发未知 bug。- 如果恰好，出现了画蛇添足的情况，代码已经提交到了远程分支，但是还没有合并，发现了自己画蛇添足了，可以使用 Git 命令删除这个分支的本地分支和远程分支，以防被下次误用。
总结： 提交代码就得跟进—测试—合并。不要想着以后再看，改动十分简单。
终极方法： 某个分支功能完成后，请删除本地及远程分支。
合理、规范的运用每一个工具，每一个技术，就不会出现那么多奇怪的问题。
绝大多数情况，只是因为我们使用工具不够熟练，并不是工具本身不够好。
Git 删除本地及远程分支方法
第一步： 查看分支git branch -a
第二步：删除本地分支，假设分支名称为 xxxgit branch -d xxx
tips：如果分支没有合并, -d 是删不掉的，需要使用 -D 强制删除
第三步：删除远程分支， 假设分支名称为 xxx
git push origin –delete xxx