前端资源迁移
目前公司的前端资源托管在svn服务器上，由于团队的逐渐扩大，svn的分支管控越来越不灵活，而且对于以后前端流程一体化的处理支持不是很好，因此决定在版本控制上转向git。git的好处不用多说：多分支并行开发，自动化构建，持续集成等等，这也是促使我们转向它的原因。
具体操作中的问题
首先尝试使用gitlab提供的web hooks进行触发脚本控制。web hooks发出的post请求我们的php文件，在php中执行相关shell脚本，完成一体化构建。但是shell中的提示输出信息无法在本地进行显示，因此即使项目构建失败，开发人员并无法在git命令行得到直观的提示，用户交互很不友好。经测试，只有放在remote端的hooks目录下的脚本输出信息才能呈现在终端，因此最终放弃此种方案。
gitlab提供的web hooks的底层实现－update.rb的逻辑是基于remote端的update hook。update hook 会在用户每次push到remote时触发，根据返回值是否为0，来决定此次push是否成功，它接收3个参数，第一个位push的引用分支名，第二个为push之前的分支sha1，第三个为push之后的sha1。update.rb封装了提供了web hooks的功能，默认通过http post请求访问我们的服务端，然后执行服务端的命令。最后，更新web界面。
其次把目光转移到remote端的hooks目录，将我们的update脚本放入hooks中，但是问题来了，由于gitlab提供的web hooks触发也是基于update脚本，而且该update脚本软连接到一个ruby脚本（所有的gitlab项目共用同一个ruby脚本），因此，无法针对前端工程制定特有的发布流程，只有手动将所有的前端工程软链接到一个ruby脚本的副本（update_f2e），在这里做法就有点曲折：
1，首先，我们在update_f2e这个ruby中先执行原有的逻辑，最后执行我们自己写的update（shell脚本），但是问题在于在update（shell脚本）中无法接收update_f2e传入的参数，而且update（shell脚本）中的提示信息也无法显示在终端，用户体验差，放弃；
2，然后针对调用流程重新构建，脚本全部ruby化。将我们的shell脚本的逻辑修改为ruby，在update_f2e中执行，问题仍然是输出信息无法显示，放弃；
3，究极版，将update_f2e这个ruby文件修改为shell脚本，在我们的shell脚本执行完毕之后，通过命令行执行原有的ruby逻辑，最终，目的达成。
说了这么多，尝试了接近几百次push，终于采用shell－>ruby的方式完成hook的无害触发，实现构建发布。
最后，方法3的方法有一个弊端，就是服务端的代码更新成功，但gitlab的web界面却无法更新，通过排查gitlab的ruby源码，发现是在gitlab-shell/lib/gitlab_update.rb中的 api.allowed?()执行失败造成，进一步深入gitlab_net.rb中，发现是我们的当前目录影响了api.allowed?方法的判断，因此在hooks/update的shell中切换到合适目录之后，解决了该问题。