V2EX › mritd 的所有回复 › 第 65 页 / 共 109 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 61 62 63 64 65 66 67 68 69 70 ... 109

❮

❯

2018-06-20 15:56:03 +08:00

回复了 york1996 创建的主题 › 程序员 › 面试的时候遇到公司介绍说自己是用 svn 来做版本管理，是否会觉得他们的技术栈比较老旧？

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

2018-06-20 15:53:21 +08:00

回复了 mritd 创建的主题 › 程序员 › 姑且算是一个 CI 实践(多图慎点)

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

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

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

2018-06-20 15:20:37 +08:00

回复了 mritd 创建的主题 › 程序员 › 姑且算是一个 CI 实践(多图慎点)

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

2018-06-20 15:19:01 +08:00

回复了 mritd 创建的主题 › 程序员 › 姑且算是一个 CI 实践(多图慎点)

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

2018-06-20 13:56:31 +08:00

回复了 mritd 创建的主题 › 程序员 › 姑且算是一个 CI 实践(多图慎点)

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

2018-06-20 13:26:10 +08:00

回复了 mritd 创建的主题 › 程序员 › 姑且算是一个 CI 实践(多图慎点)

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

2018-06-20 13:24:18 +08:00

回复了 york1996 创建的主题 › 程序员 › 面试的时候遇到公司介绍说自己是用 svn 来做版本管理，是否会觉得他们的技术栈比较老旧？

@lixuedong gif

2018-06-20 12:20:48 +08:00

回复了 ColinZeb 创建的主题 › 分享发现 › iOS 羊毛， 1 分充值六元

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