@hansonwang99 #21 加了你友链 https://i.imgur.com/lRqA9em.png

别写简书了，搞个个人博客

没移动需求我建议你，友情提示 黑苹果淘宝搜 DSDT 的靠谱 不做的都坑

跑路就完了

原谅我的好奇心....公司为啥有蚊子 (´･_･`)?

@dexterzzz #24 这个贴子只是我对 opnsource CI 整理的一套工具链，如果硬对比商业版工具我敢保证有很多比它们还牛逼的，就算是商业版也无法做到每个方面都 ok，比如 提交规范、工作流的建立

哇，这是真的丑

Talk is cheap, show me the code!

@lixuedong #145 (´･_･`) ..... 我只能告诉你 我传上去的事 gif...至于它为什么变成了一个 png 地址 我就布吉岛了

@feiyuanqiu #21 这个是个粒度问题，如果你的提交以功能为单位，那么当一个功能 ok 以后应当放入 测试环境测试，这时候有问题进行 fix 我感觉在 CHANGELOG 里是没什么问题的；如果以修改为单位提交 那么出现在 CHANGELOG 里会有点多，可以考虑用其他的；

那个 CHANGELOG 生成工具可以自己定义的 https://i.imgur.com/xGx2YUe.png

还有就是实际上这个 CHANGELOG 应该是面向开发人员的，我感觉多点少点无所谓，我只是想通过看到每个版本之间我们开发变动了什么东西；而对于类似 app 发版啥的这种 CHANGELOG 肯定是手写一个符合普通大众理解的

@feiyuanqiu 其实 gitflow 目前没有完全的统一标准，这东西存在的意义就是对 提交修改清晰化、测试部署流程化，你只要在几大模型中找寻出适合你的就可以

@feiyuanqiu #18 我目前的做法是，commit message 中对于修复性提交全部走 `fix(scope): subject` 这种格式；分支名称上，对于新功能应当从 develop checkout 新分支，且以 `feat/xxxx` 形式命名，只会合并到 develop 分支；对于线上问题紧急修复，从 master 创建分支，以 `hotfix/xxxx` 命名，ok 后同时合并到 master 与 develop ；最终原则是 master 要时刻保持和生产一致，develop 作为开发日常修改

@ShineSmile #13 runner 直接调用脚本应该是可以的，不过我记着 .net 后端项目好像可以在 docker 里跑，然后扔在 linux 上

@gamexg 这个没麻烦啊，基础镜像做好了就行了，dockerfile 写好 有 cache 的，https://mritd.me/2017/11/12/ci-cd-dockerfile/

@lixuedong gif

6 块钱一个身份证号 (•ิ_•ิ)?

@gamexg #9 黑人问号.gif

什么网络影响 (´･_･`)?
gitlab ce 私有化部署，然后再部署一个 gitlab runner 链接就行啊，都是内网私有化啊