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

[0littleboy]

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

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

[FishBear]

合理,为什么不合理,你刚毕业吗?

[pkoukk]

非常合理，谁没事干看 log 去

[Parva]

合理个 der

[securityCoding]

合理，标准的开源流程

[qsnow6]

合理

[berrybeberry]

方便回溯，不是挺好的吗

[javalaw2010]

合理。
不过如果团队规模较小，可以向负责人提出建议表示流程繁琐可以适当简化这个流程，小的 feature 或者 bugfix 可以在一个主干分支上完成。

[LotusChuan]

从你的描述来看挺合理的，建 issue 和建单独 branch 是耗时很久的操作吗？后续复盘的时候，issue 可以记录完整的开发过程；而用 git log 只能到时候 grep 一下，并且如果哪个人 log 没写关键词，他的 commit 基本找不到。很难想象 branch 都懒得建的人能写出多么规范的 commit message 。

[FukArtorias]

非常合理

[Lockroach]

几个人的小团队的话我个人感觉没啥必要，合理是合理的

[kakakakaka8889]

怎么不合理？我们还一个需求一个分支呢，bug 是 bug 分支，hotfix 是 hotfix 分支

[0littleboy]

嗯，其实现在就我一个人开发这个

[ExplodingDragon]

> 嗯，其实现在就我一个人开发这个

@0littleboy 不是协作开发没必要，如果不用汇报的话那就更没必要了

[h1298841903]

可以考虑写一个指令，自动创建分支，以及名称。

[m1nm13]

过度设计,万恶之源,不论是代码上,还是流程管理上都是如此

[w568w]

多人开发非常合理。胡乱提交，等出问题或写日志的时候，就对着 commit 里一堆「 fix 、bug 、功能、a 、1 」哭去吧。

单人开发就随意了，可能 leader 有意要树立团队协作习惯。既然你之前从没接触过协作开发（否则也不会问出这种问题），我觉得学习一下挺好的，不用抵触。

[ckdxc]

看项目复杂程度吧, 如果是平台类或者只需要维护一个版本 master|main, 确实 git log 就能看完了
但是如果是多版本, 或者代码仓里面贼多模块, 有 issue 管理会稍好一些, 如果是更大的项目涉及多个仓库, 那 issue 可能也不好使了, 得用专门的管理软件

[lavvrence]

本来就应该这样，每个功能或 Bug 都要在单独的分支上实现。
哪个先实现好了随时合并到 代发布的生产分支 或者 测试用的分支。

[hyqCrystal]

其实 bug 解决完 要即使删除清理 这样做是合理的，不然的话 整个代码管理 看似用了规范，反而会导致更加混乱

[touchwithe]

合理