开发流程
现假设我们接到一个需求，需要为某个用户的活动隐藏开始游戏的按钮。对于这样的功能，我们的工作台上是无法实现，工作台可以修改开始游戏按钮的图片或者颜色，但是无法实现修改大小甚至是隐藏这样的高级定制功能，所以我们需要帮助该用户实现此功能。
活动ID
针对一个这样的修改，与我们对接的相关人员会给予我们一个外网的活动ID，也即是game_id值，此值是用户到时候推广的活动ID，也是到时候发布后的正式链接ID。
我们每次修改之前，都应该创建一个测试ID进行测试。测试通过后才把代码更新外网。
内外网环境
这个是我们的外网地址。但是我们修改代码的时候必须在内网经过系列测试，确保没问题后才更新到外网。
这是我们的内网地址。我们在内网根据对应的模板创建了ID后，便可以使用这个测试ID进行相关测试。
准备
拿到了测试ID后，我们不用着急修改。如果是第一次修改，先把24haowan_front_game库给拉到本地。除了活动页(游戏逻辑)以外的代码，都是写在我们的通用代码库24haowan_front_game中，所以此次的修改需求是隐藏开始游戏按钮，那么我们也就要在24haowan_front_game库中修改。
建立分支
如果是两个人以上的协同开发，要求要有一条上游分支，双方把修改的内容都推到上游分支里面，最终修改完成后再把上游分支合并到Master上。
如果只有一个人进行开发，那么不需要上游分支，但是需要在本地建立一条功能分支，修改完毕后在Github上发起PR，把功能分支合并到Master分支后即可。
功能分支建立说明
- master : 主分支，该分支上的代码必须都是经过测试，可发布的
- custom_xxx : 客户的定制定制
- fix_xxx : 修BUG的分支
- opt_xxx : 优化某个功能的分支
- feature_xxx : 功能开发分支
因为此次的修改是客户定制的功能，所以新建分支
git checkout -b custom_xx客户隐藏开始游戏按钮
修改代码
我们打开24haowan_front_game库，跳到
24haowan --> js --> t --> modules --> public --> custom.js
这份custom.js是定制组预留代码，专用于修改客户的定制需求。执行的生命周期是
游戏的通用代码块初始化 --> custom.js --> 模板的游戏逻辑代码(game_tpl里面的逻辑代码)
我们在custom.js中可以做出以下修改
if(game_id = xxx){
$('开始游戏按钮').css({
'color' : '#fff',
'backgroundColor' : '#000'
})
}
推送分支
修改完毕后，把分支推到Github上
git add .
git commit -m '测试修改是否生效'
git push origin custom_xx客户隐藏开始游戏按钮
这样我们的代码就可以推送到了远端的Github上，此时我们必须通过内部的一次构建工具进行相关的代码构建，才会让本次的修改生效，然后才能看到测试效果。
构建代码
构建工具地址如下
如果是第一次推送分支，那么我们必须同步一次远端分支才能把Github上的新分支拉到构建工具上。
比如这时我们需要在24haowan_front_game上点击同步远端分支。等待完毕后，便可以在24haowan_front_game的下拉框中看到拉取回来的分支。我们选中需要构建的分支
点击构建后我们便可以看到代码修改的效果了。
PR
经过测试后，如果修改的代码确认没问题，那么我们便可以把测试ID修改为正式ID。然后再次推送分支。并到Github上建立一个PR，即pull request请求把分支合送到Master分支上。
提完了PR之后，把相关的PR地址交给组内的其他前端进行审核。代码审核通过后，同事会帮你把代码更新到外网。
之后便可以在正式地址上进行测试，看看修改是否存在其他问题。
完毕
至此，一个修改的流程完毕。