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

[0littleboy]

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

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

[LHRUN]

非常合理, 公司能这么规范你就偷着乐吧

[Nzelites]

单人开发的话我认为可以不用，多人的话很合理

[RangerWolf]

你个人的项目 你怎么开心怎么来

公司的项目，很合理，即使开发者就你自己一个人
养成好习惯，也是一种成长

[RangerWolf]

@ExplodingFKL 个人认为，如果是公司的项目 即使只有自己一个开发者，也应该按照这种比较科学合理的流程来进行代码提交

[livin2]

合理，但如果 "每一个都"的话，要结合里程碑控制合并的优先级和数量，还要避免分支的生命周期过长。

[Oxonomy]

学习一下什么是 TBD ，trunk based development

[yankebupt]

如果你一个人负责到死，log 就行了。如果将来准备甩锅给另外一个人，那么如果他能做到查 issue 就知道什么 bug 什么时候修复了怎么修的，交接会轻松不少。当然代码量如果很低（几 k ）的话就没必要了。

[zsh2517]

感觉关键在于如何看待 issue （或者类似的东西）

issue 是作为代码库的附属，只跟踪重要内容比如 BUG 、大型迭代等，上面只记录了需求内容
还是软件迭代的一环，从需求提出（为什么要改代码/期望实现什么收益）跟踪到上线甚至收益回顾（实际带来了什么收益）

后者的模式下，整个迭代流程可以被 issue 串起来，简化一下——PM 创建 issue ，然后 PMO 指派给相关人员；开发根据 issue 关联代码提交； QA 根据 issue 关联的代码库和分支进行测试，创建 bug 关联 issue ；上线时任务与需求绑定；最后 PM 再回顾这个需求的收益。

[mikewang]

挺合理的，而且我会把为什么出 bug 、bug 是什么样的表现、怎么修的等大致思路等等都写上。
以后遇到类似问题或需要复盘的时候，翻找起来很容易。很多时候，人的记性没想象的那么好，多写点没什么坏处。
除非是开发的一次性工具，用完就再也不维护的那种，那就随意了。

[panbeta]

对于小于 10 人合作开发的 Git 来说没必要如此复杂。 实际上 issue tracker 系统和 Git 可以通过其他方式结合。例如：每个版本发布前的 bugfix 阶段，拉 bugfix 分支统一修复本版本需要修复的 bug 。 每个 bug 单独一个 commit ，commit 中添加 「 fix: #ID 」的描述，issue tracker 系统收到 hook 通知后解析 commit message 来关联提交记录到工单就可以了。后期回溯直接从工单系统找就行了。

[satoru]

关键在于谁来建 issue
打个比方，如果公司内部有人给你报 bug ，他不写 issue 而是通过聊天工具或者口头传达，然后你来建 issue ，这样就不合理

[mikawang]

很合理，但是小公司就几个人没必要，中大公司还是需要

[wangtian2020]

小团队没必要，过于教条了，有种技术负责人刚出高校的一种菜逼美

[zhanglintc]

非常合理

[AlexHsu]

合理 但是没必要

[shm7]

gitlab 标准流程类似

[unco020511]

合理的,但如果你的团队真的很小,那么是应该简化的

[NoKey]

都在一个分支，某个修改出了问题要回滚，咋整~

[sn0wdr1am]

非常合理，可追溯，可协同。

[ZoeMak]

产生这个问题的根本原因应该是有人在一个提交做了多件事情。
最重要其实是一个 issue 只干一件事，一个 commit 只关联一个 issue 。
清晰明了，双向回溯。