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

[0littleboy]

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

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

[xizh007]

很标准的流程 羡慕

[location123]

合理 好公司

[foolishcrab]

觉得不合理的时候想想你自己会不会在 commit msg 里写小作文介绍需求背景，代码设计。
你能做到的话公司要求把这些信息放到外部文档又能费多大事呢？

[Immunize]

多人开发的时候一般都是产品经理创建需求单/Bug 单，可以对应你这里的 issue 。然后你在一个独立分支上开发，发起 MR 的时候关联上，这样就能知道特定需求/Bug 的处理情况了，便于后续溯源。否则干了半年都不记得干了啥，为啥干了。

[dwu8555]

相当合理，不过一两个 dev 人员就没必要

[jiangxiaoshui]

1 个人不太合理，不过这样做也行。

只要 1 个人以上一定要用分支来管理，多人在一个分支操作出现对本身分支造成破坏性的操作就完了，在个人分支上出现这种操作也只是在这个分支，控制了影响范围。

[sparrowMan]

@0littleboy #12 非常合理，即使是你一个人开放，你能保证 fix 的、修改的 、新增的 都能按期上线吗？ 平时开发都是一个问题一个分支，然后根据进度和需求，挑选若干分支进行合并发版

[iugo]

如果是已知小问题并且没有建立 issue, 可以不建立 issue, 但至少要有 PR 及相关的分支吧.

[kneo]

这叫项目管理。

[0xABCD]

合理，方便回溯当时做某个需求的背景

[guanzhangzhang]

看到好多人 commit 信息写😂
- fix
- fix bug
- fix build
- update
- test

[35aZ4P8mT576683q]

首先合理，其次显得你工作量大

[momogzp]

合理, 其实一个人也是需要分支管理的. 有时候搞一个需求, 搞到一半, 有一个着急的 hotfix, 你不能就在需求分支上搞吧?

而且一个 issue 和一个分支对应也挺对的. 以后遇到同样的问题, 有 issue 跟踪, 还有 fix 的 commit. 想想以后要在上千个 commit 中找到某个 bugfix 得多难.

[cumt21g]

非常合理, 理由上面的同学都说了
如果是一个人开发也合理, 有一天有人问起你这个地方为什么这么做,你可以把相关的 issue 链接甩给他,虽然繁琐,但是也是一种自我保护机制

[changnet]

每一个功能或 bug 都要新开一个 issue 我觉得是合理的。但一个 issue 一个分支这个理论上也合理，但操作太繁琐了吧，我从来没用过，需要切一个分支，后面还要合并。

[ldw2046]

必须合理啊，项目稍微复杂点，不这样弄，代码会成屎山代码。

[ldw2046]

@hyqCrystal gitlab merge 到主干的时候默认删分支，所以其实还好，看着很清爽

[davin]

git 提交时，可以跟一些第三方协作工具的 webhook 合作，直接链接到对应 issue ，撕逼的时候方便看到原因

[cccvno1]

只要是公司项目这样都合理，开发的代码属于公司资产，完备明确的流程是公司对自己资产的保护。比如一些稳定运行了很多年没有变更的项目，要有新的功能变动，当时的开发者可能已经离职了，没离职也不能有多深的记忆，这时候这些 issue 的价值就体现出来了。
既然公司规定了就好好执行（又不是什么脑残规定），大项目遵守、小项目不遵守到最后肯定就都是一地鸡毛，git log 都不见得好好写了，所以口子一点不能松。

[BruceXu]

不合理...需求和 bug 可以单开分支,定期合并.

没有必要为每一个需求甚至每一个 bug 单独开分支.

new branch>commit>merge>delete branch.真是吃饱了撑得.