我们现在要求每一行代码的 commit 信息都要关联上任务编号,然后代码量+任务复杂度等来计算开发效率。
|  |      1Dockerfile      2021-10-29 09:50:09 +08:00 一样 任务号 + perf/fix/feat + ... | 
|  |      2wu67      2021-10-29 09:51:36 +08:00 要按提交内容的类型区分, 还要抓个人过来人肉 review, 然后把对方名字写进 commit msg... | 
|      3cppc      2021-10-29 09:59:24 +08:00 意思是不分任务就不能提代码,开发人员干活只认任务编号不认人? | 
|  |      4shanghai1943      2021-10-29 10:05:04 +08:00 好奇,有多少公司会计算开发效率的?之前貌似没怎么碰到过。 | 
|  |      5wenqiang1208      2021-10-29 10:06:46 +08:00  2 开发效率 本来就没办法量化的, 对代码的熟悉程度,复杂度,个人等级都有关系的 | 
|  |      6ElegantOfKing      2021-10-29 10:09:06 +08:00 comit 限定信息:任务号 fix or feature 提交详情 | 
|  |      7MuscleOf2016 OP @cppc 现在造成这种恶性结果了,有的小组长已经指挥不动手下人了,小改动,就要任务编号。然后只能组长自己改。选择忽略扫描的 commit msg | 
|  |      8NillSpake      2021-10-29 10:14:58 +08:00 觉得没什么大问题吧,我们用的 jira ,所有任务分配任务编号 TM-XX ,优先级。 所有任务开分支命名 姓名 /TM-XX-任务描述 ,commit 也是如此,代码注释也是如此。 | 
|  |      9NillSpake      2021-10-29 10:16:41 +08:00 而且本身,我们修改一个 button rename 都会有一个任务。 但是以此作为来计算开发效率,就开始卷了。 | 
|  |      10cyrivlclth      2021-10-29 10:16:46 +08:00 没啥要求,就一个 commit 模板,feat\fix\chore\refactor+Closes#Issue | 
|      11joesonw      2021-10-29 10:18:43 +08:00 跑 | 
|      12x940727      2021-10-29 10:21:19 +08:00 @MuscleOf2016 这样挺好的啊,顶多就是小组长麻烦点,多拿钱多干事呗,大不了给老板说不写代码了就专门管这些也不是不行啊。 | 
|  |      13FallenMax      2021-10-29 10:21:28 +08:00 跑 | 
|      14hccsoul      2021-10-29 10:22:06 +08:00 没有 ..随便提交 | 
|  |      15coderluan      2021-10-29 10:35:29 +08:00  1 没限制,有些同事连 git 是干啥的都不知道,完全是当网盘用的。 有次让一大哥先上传个原始版本,再把最终版本提交上去,结果大哥建了两个文件夹,一个原始版本,一个最终版本。至于各种大号 bin/dll 都往上传也是常态,我说你这样再 clone 会很麻烦,他们说那我删了呗,草。 | 
|  |      16cuzfinal      2021-10-29 10:44:16 +08:00 没有要求,随便搞。 | 
|  |      17legiorange      2021-10-29 10:46:47 +08:00 Jira 号 + Jira 号的 title + 描述 代码量+任务复杂度等来计算开发效率不现实 | 
|      18zqx      2021-10-29 10:58:18 +08:00 via Android github 很多项目都是注释里带着 issue 链接 | 
|  |      19yrhhh      2021-10-29 10:59:57 +08:00 commit 信息:更新 | 
|  |      20dangyuluo      2021-10-29 11:18:23 +08:00  7 不许有脏话 | 
|      21cndydb      2021-10-29 11:20:35 +08:00 可以为空 | 
|      22chaodada      2021-10-29 11:25:36 +08:00  5 commit 信息:123  commit 信息:第一次提交 commit 信息:测试 commit 信息:1 commit 信息:修复 xxx commit 信息:修复 xxxxxx | 
|      23Yuan2One      2021-10-29 11:37:50 +08:00 [issus/需求 US/问题单号][feat/fix/docs/style/refactor/test/chore] 功能变更描述 | 
|  |      24andyskaura      2021-10-29 12:00:04 +08:00 | 
|  |      26oppoic      2021-10-29 12:35:00 +08:00 不准打 “1111” 或者 “---” 之类的 | 
|  |      27wellsc      2021-10-29 13:01:46 +08:00 commit 也这么严吗? merge request 或者 branch 严格一点还能接受 | 
|  |      28openmm      2021-10-29 14:03:05 +08:00 啥是任务号? | 
|  |      29chenzheyu      2021-10-29 14:07:06 +08:00 代码量?写业务不行,写废话不是很简单的事情吗? | 
|      30chenyi      2021-10-29 14:20:27 +08:00 commit 的用户名必须要跟自己的用户名一致( | 
|  |      31xnth97      2021-10-29 14:38:04 +08:00 commit 时 CI 自动跑一些东西,比如 linter 检查 code style 、precommit 跑一遍测试、postcommit 跑一遍测试 | 
|  |      32SmaliYu      2021-10-29 14:41:00 +08:00 不许写拼音…… | 
|  |      33otakustay      2021-10-29 14:43:18 +08:00 @MuscleOf2016 组长没有权限创建一个任务吗? | 
|  |      34JoeBreeze      2021-10-29 14:47:18 +08:00 我们组随便, 必要的时候能找到人背锅就好 | 
|      35ckaock      2021-10-29 14:55:21 +08:00 换老板 | 
|      37isBitter      2021-10-29 16:04:01 +08:00 https://github.com/streamich/git-cz 加了个 pre-commit-hook 另外大概的 review 下命名,代码组织... 至于 merge 或 rebase 没要求。 | 
|  |      38pengtdyd      2021-10-29 16:10:40 +08:00 直接分模块开发不就好了,哪这么麻烦,小公司还弄一套繁琐的流程,最后自己累死自己 | 
|  |      39iovekkk      2021-10-29 16:22:15 +08:00 之前的公司,打通了需求录入系统、开发 gitlab 以及缺陷管理系统 从产品录入一个需求开始,转到研发这里,确认之后会自动创建一个分支 研发在这个分支上开发完成,在系统上确认完成以后,会自动打包然后提测,流程就到测试那里去了 测试验收以后,这个功能分支又会自动合并到开发分支上 | 
|      400Vincent0Zhang0      2021-10-29 16:27:33 +08:00 via Android 任务复杂度怎么考虑的? 大家按最简单的方法完成? 不考虑维护和扩展性? 需求不提边界就尽量不考虑校验? 这种 KPI 只会扭曲结果。 | 
|      41rgxiao      2021-10-29 16:31:31 +08:00 要求是只要能跑起来, 不管是三条腿跑起来的还是一条腿跑起来的, 反正能跑起来就可以了. | 
|  |      42haozheliu      2021-10-29 16:33:09 +08:00 必须是公司邮箱,加上 jira 的 issue 号 | 
|  |      43mmrindextt      2021-10-29 17:22:01 +08:00 还是要有一定的规范,写起来才会舒服。 | 
|  |      44Merlini      2021-10-29 17:28:07 +08:00 JIRA 号和内容概括 | 
|  |      45k9982874      2021-10-29 18:36:34 +08:00 via Android @coderluan 巡检 repo 时发现 ios 组的 repo 高达 1 个 g ,一看 ios 的同学把 pods 提交上来了,就离谱 | 
|  |      47zzlatan      2021-10-29 18:59:02 +08:00 真羡慕你们业务这么闲。。。 | 
|  |      50rannnn      2021-10-29 22:55:17 +08:00 - 每一个 commit 都要单独 review  - 只 rebase 不 branch 不 merge - 因为没有 branch 提交到 master 要排队 rebase | 
|      51Rache1      2021-10-29 23:41:57 +08:00 PR 时要有任务编号,标题尽量一句话描述清楚。 我用 alias 做了 commit 自动获取分支名上的任务编号填到 commit 中去,所以 commit 里面也就有了,主要是方便后期定位是哪个需求造成的改动。 | 
|  |      53clf      2021-10-30 01:40:37 +08:00 via Android gitmoji + issue + 说明 | 
|  |      54sagaxu      2021-10-30 06:56:09 +08:00 via Android 曾经试行过,不但要有 task id ,每个 task 在进度表上不能超过半天,超过半天的都要拆分细化,周报中至少要有 10 个 task 。如果有 1 小时以上的会议,会议也要提一个 task ,否则时间对不上。 | 
|  |      55Nich0la5      2021-10-30 11:08:17 +08:00 原则上 commit 肯定要带编号的  系统要管理到这次改动影响哪个 bug 或者关联哪次迭代,(虽然我们这边有挺多人 commit 挺随意的就是了) | 
|  |      56darkengine      2021-10-30 11:11:50 +08:00 commit 信息都要关联上任务编号 (JIRA issue/task ID)属于基本操作了吧,以后查问题(找人背锅)也好找。 | 
|  |      58susecjh      2021-10-31 14:51:49 +08:00 Feature/FIx/... + 描述即可 |