公司每一个功能或 bug 都要新开一个 issue，合理吗

[0littleboy]

比如我要开发一个新功能 A 和解决一个 bug B 就需要建立 issueA ，issueB 然后根据 issue 编号建立，如分支 t_32 解决 issueA ，t_33 解决 issueB 这种方式合理吗？

我感觉很麻烦，明明通过 git log 就能区分的事情，需要额外做挺多事 而且这个项目也没几个人开发

[htxy1985]

从管理角度当然很合理，但在效率上是灾难，更别提还有别的指标，具体如何平衡完全看此项目的上下文场景。

[mxT52CRuqR6o5]

git log 就代表只有开发能参与到其中，产品、测试、设计都没法参与了

[wqq096737ink]

当然合理了, 出了问题好追责,免得跟这种人扯皮

[linzyjx]

非常合理，要不然怎么算工作量（ x
真要说每个 issue 要填工时的。

就两三个人的小团队可以把颗粒度调高一些，比如一些功能添加可以搞，一些真的很小的就看情况。
具体就可以看一下 gitlab 的实践了

[zw1one]

@m1nm13 加一句：没有银弹。 一个规范不考虑实际情况就套用，也是把 git 规范银弹论了。

[oops1900]

很合理呢，不同分支解决的问题都可以部署测试。互不干扰。公司这是让你有良好的习惯。

[volantRookie]

相当合理

[peeves]

等需求没沟通（设计）好需要扯皮、需要分锅的时候你就知道合不合理了

[yangyaofei]

合理不合理看是什么样的项目, 多少人维护, 有没有自动化的测试.

原来我也觉得这样是对的(绝对正确的那种), 但是要是就 3 人精力有限, 还前期经常改动 bug 无数需求无数 的时候,
这样做就变成政治正确了.

个人觉得:

1. 人少的时候能保证单个提交是一个 issue 就很不错了
2. 经常改动的时候, 逻辑上一起的东西一块提交就行了

有无限的人力和无限长的 deadline 另算, 优雅和漂亮是有成本的, 在有限的时间和精力下尽量优雅就算可以了.有些人真的是连内容都不看就喷啊

[eijnix]

你这算啥，我们这改任何代码都要建立对应的 jira 单的，tech, feature, bug 。 并且 git hook 的 pre commit 要从 branch 名提取单号，注入到 commit msg 里。
好处就是之后看问题很方便，之后看这行代码就能从 jira 里追溯到当时为什么要改这里。

[iguess]

合理，但你一个人，那就不合适。

[cnhbwhm]

我觉得需求可以一个 需求 一个 单独的工单，
但是如果只是简单的 bug 修复 ，我觉得没必要

[17681880207]

意思是每次 commit 只解决一个 bug 或者 feature 嘛？😂

[Rickkkkkkk]

你可以把你感觉不合理的点以及改进方案整理一下，然后组里分享。

如果提的确实有道理，会改的。

[zephyru]

你问合不合理那肯定是合理的。
但你问合不合适，那就是看情况了。
如果 bug 和需求可以单独上线，基本是要单独拉分支的，方便管理。
你不能保证哪个会先要或者后要还是一起上线。
你如果能保证就是一起上板上钉钉，绝对不会改，混在一起问题也不大，不过看这架势拍板的估计也不是你...

[duanzhanling]

非常合理

[hegfirose]

项目里写个简单的脚本，把建 issue 和建分支的工作同时做了就好了

[Chuckle]

合理啊，标准流程，内部工单系统，一个工单对应一个新功能需求，然后内部流水线系统能管理分支和工单，写完推送就自动部署测试环境。

[kneep]

不但合理，而且我们要求每个 commit msg 都要关联票号，没票不允许提交代码。双向追溯。

[icanfork]

应该从程序上限制你不关联 issue 单号就不允许你提交 commit 才合理