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

[0littleboy]

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

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

[FishBear]

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

[pkoukk]

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

[Parva]

合理个 der

[securityCoding]

合理，标准的开源流程

[qsnow6]

合理

[earthyan]

方便回溯，不是挺好的吗

[javalaw2010]

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

[LotusChuan]

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

[FukArtorias]

非常合理

[Lockroach]

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

[kakakakaka8889]

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

[0littleboy]

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

[ExplodingFKL]

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

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

[h1298841903]

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

[m1nm13]

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

[w568w]

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

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

[ckdxc]

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

[jaylee4869]

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

[hyqCrystal]

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

[touchwithe]

合理

[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

[liberty1900]

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

[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 都不见得好好写了，所以口子一点不能松。

[xubingok]

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

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

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

[harlen]

我同事就喜欢在主分支上干事，没次他有 bug 整个项目组都得等他把 bug 修复好，才能正常开发，光明正大的摸鱼，最后结果裁员的时候，就他没被裁

[sexyback]

就去过两家公司，都是这么做的，我觉得挺合理的，无非是分支切换麻烦一些

[Valpha6]

用分支管理或者用 git comment 管理都有道理，主要看分支策略。单主分支瀑布交付用 git log + 模板约束一样可以实现管理和质量的诉求。多人合作且对过程版本有要求，那建 issue 分支同样重要。都是合理的流程，要看公司的质量要求如何

[guiyumin]

Too young

[timeance]

等你年度汇报的时候就发现能一键统计工作量太有用了

[kermitlee]

合理，羡慕+1

[donaldturinglee]

大项目的 git log 非常的长，除非需要审查，一般都不怎么看。 我修 bug 是新建一个临时的 fix bug 分支，然后在 commit 里面对应 issue 的 id ，最后再把 fix bug 分支删了

[kk2syc]

朋友公司十几年的 smb+版本 zip+readme.txt ，20 多人团队，没出过问题，所以用什么无所谓，关键是大家都能接受

[myderr]

我还想要这种管理呢，我们现在十来个人都在 master 上一把挫

[zacard]

合理。项目越复杂，协作人越多，好处越多

[picone]

合理。
除非你 git log 能把详细的上下文贴上去，不然的话在 PR 上加上，一般都做不到，Issue 是最保底的方式。不然几年后别人接盘你的代码不知道你为什么改

[Int100]

合理。请养成好习惯。

[punkerhyde]

你不想标准，你以后工作当中碰到不标准的也不要叫，就是这样

[NealLason]

非常合理！

[NoManPlay]

可以了解一下 git flow

[shiny]

几年后你在不在公司都不知道，接手的人看 issue 和看 git log 哪个容易

[msg7086]

个人开发的话不合理，几十个人的大组开发的话这是基本要求。
我们不光每个工作要开 Jira ，并且每个更改都需要写 Confluence Page ，把修改案、测试用例和测试结果都写在里面。万一程序发出去了出了问题，都有文档可以查证复盘，做了哪些工作，哪些漏了以后需要改进，等等。
反正我带薪写 issue 带薪建分支，又没亏待我。

[msg7086]

当然你要说你有本事把流程图和需求和测试全部写在 commit message 里那我敬你是条汉子。

[iyaozhen]

合理 大公司都这样（不是说大公司一定是对的

一般来说工作都是面向 issue （或者类似的），分支倒没有强制，但一般项目系统都给你分支拉好了。
就是你的所有开发工作（新需求+bugfix ）都是要 issue ，就是你不能打黑工（即使你是技术调研都需要建一个子任务），这样方方面面才有迹可循。测试也是一样手工 case 、提的 bug 都需要关联起来

[adoal]

开一休是处理具体问题的前置事件，看老哥则是后置事件。

[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 的方式去做？

[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 都要关联票号，没票不允许提交代码。双向追溯。

[belin520]

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