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

[0littleboy]

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

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

[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]

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