合代码de内心独白
上周五产线领导派了一个活，合并前端和后端rest服务的代码，release合到develop。其实是一个很简单很日常的工作，但是因为种种原因，现在的版本周期过长，导致新增和修改的代码很多（特别是前端一堆的css、less、jsx、js….）。所以你知道我心中有多少只草泥马了。
这个时候需要的是冷静，蛋定。找个本子合一支笔，列清楚怎么做这件事情，一定要花时间考虑清楚再下手。
行动清单
摸清楚分支情况，看看改动到底有多大，根据摸排的情况，判断是否需要上升到领导，因为如果动作太大势必会对团队的一些代码方面的操作有影响，需要领导提供协助，让团队配合合理解。
把涉及到修改人都和其确认一下，代码改动的分支以及模块，看是否与自己的理解存在误差，及时修正误差。
借助命令（git log、git diff、git show…）以及工具（meld）对代码进行比对合并，设计面广最好不要直接往develop上合，先拉一个本地分支往上合，合完之后，验证通过再往develop合并。
合并之前，明确通知合并开始的时间点，并告知团队此时间段内不要再往分支上提交代码。
合并代码的时候手别抖，心别慌，扎稳马步，看清楚再合并，其实也不怕，因为你是单独拉的分支，哪怕整坏了也无所谓。所以就跟开车一样，胆大心细。
合并完之后，本地测试是否功能有问题，一定要测。
合并代码有个坑，在于自动合并，它往往会给人错觉表示这块代码或者这几个文件时没问题的，但是很多时候往往是有问题，因为git并不知道这几个文件是否存在因果联系，这样就往往容易漏掉。我就遇到了这个问题，合并代码之后哪儿都ok就是一直提示license有问题，几个人轮番查了几波，排除了可能的原因，最终就落到了代码合并上，猜测是代码合并造成的，所以就查代码，最后发现确实是权限过滤的url那儿没有添加上license相关的url，导致license的url每次都被拦截了。
小结
干越复杂越麻烦的事，越不能心慌，理清思路，列出行动项，一个个啃掉。