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

[0littleboy]

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

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

[DamonLin]

合理，之前在 10 个人的开发团队就是这样的，切换新的分支 issue 让大家都知道到底在干什么，追溯问题也非常容易，开发组长在合并 master 就知道每个分支具体在操作哪块代码。

[AoEiuV020JP]

如果这项目只有两三个人开发，搞那么多分支不大合理，还不如要改什么喊一声，

[NewMoorj]

合理，有外企风格，蚂蚁虽小五脏俱全，只有流程管理到位了，才不会出现那种半夜喊你起来，或者休假中 call 你的事

[q2677855779]

合理的，git 分支不就是给你做这个的嘛，专门的分支搞专门的事情，上面也兄弟说的好，你改着改着，要做其他紧急的需求或者 bug 咋办？

[cyrivlclth]

@AoEiuV020JP 确实，两三个人的话，为了防止有冲突，自己要推送的时候让别人不要开发，避免冲突 [狗头]

[wysnxzm]

想省事不按规则来那就要接受解决非常规问题付出的更多成本,每一条规则的背后都是经验教训

[bojackhorseman]

@harlen bug 写的太多不可替代性太强，裁了没人能修复了

[bojackhorseman]

公司项目也只我一个人维护，开发新需求我都会 git flow feature start 一下

[gefranks]

很合理, 这样的流程是在保护你.
确保改动都有记录, 代码和 git log 一般只有开发用 但 release 一个功能, 修一个 bug 参与的人上下都有很多
不要在改一个东西的代码里夹带其他的改动.

之前公司里有这个流程, 但是开发不遵守,时不时的夹带其他的改动, 然后出过好些次线上的大小问题
现在大部分都老实了.

[wzzyj8]

1. 合理
2. 你不能假设所有的人在同一个公司+同一个组永远待着，所以你需要有 jira backlog
3. 最重要的事情应该被先完成，也就是哪怕有一个简单的 bug ，如果优先级低，不应该在随机的一个 PR 里和别的 feature 混在一起修复。这样做最大的问题是 release/rollout 会有困难，同时增加 oncall 追踪问题的负担。出现需要滚回的情况会发现依托答辩根本不知道哪里的问题。

[houshuu]

不分开要是一个功能挂了你想单独拎出来 rollback 还得去看 commit ？风险太大了，说不定还得解决 conflict
以前做过没有 blue green deploy 的项目，rollback 完成前的每秒钟都在造成巨额损失，能快一点就是一点。分开来至少直接 rollback 一个 squash merge 的 commit （ pr ）就行

[qinxi]

对比一下. 你喜欢哪一种?

[DinnyXu]

首先你不要站在开发的角度思考问题，一个流程完善的公司，比如我们是这样操作的，我们在首次提测后，如果有新功能 A 开发，同时也有 bugB 要解决，我们会提供 ai-ocr/-/tags/1.1.1_T20250326_1 , 这个里面有新功能 A ，但是 bug B 我正在修改，所以代码不在其中，如果我 bugB 也修改完了，我会再打一个类似的 TAG ，这样做的目的是测试在执行用例的时候如果系统报错阻塞了，测试能够第一时间根据 TAG 回滚到上一个版本，不至于影响他接下来的测试

[yb2313]

真写在一块了你又要哭

[xz410236056]

@sparrowMan 说不定明天公司都没了，别在这过度设计了哥。

[337136897]

相当合理

[Aqued]

合理，因为有的需求做的做的可能就没了，你都放在一起后面摘都费劲， 还有将来出了问题 可以根据 commit 信息追溯到分支 并且追溯到任务

[hefish]

我觉得 op 说的很对，完全不需要那么多 issue ， 一个项目只需要一个 issue 就可以了。

[Scarb]

合理啊，git log 只写改动，但是没有为什么要改之类的背景，以及改动设计、测试结果等等。这些都可以写在 issue 里。
不然很容易就不记得一个地方为什么这么改了

[mxT52CRuqR6o5]

比如提了个一个 bug 的 issue 单，但最后发现是 feature 不进行代码提交，这种场景你准备杂用 git log 的方式去做？