这是一个创建于 199 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如我要开发一个新功能 A 和解决一个 bug B 就需要建立 issueA ，issueB 然后根据 issue 编号建立，如分支 t_32 解决 issueA ，t_33 解决 issueB 这种方式合理吗？
我感觉很麻烦，明明通过 git log 就能区分的事情，需要额外做挺多事 而且这个项目也没几个人开发
 | 1 FishBear 199 天前  127 合理,为什么不合理,你刚毕业吗? |
 | 2 pkoukk 199 天前 非常合理，谁没事干看 log 去 |
 | 3 Parva 199 天前 合理个 der |
 | 4 securityCoding 199 天前 合理，标准的开源流程 |
 | 5 qsnow6 199 天前 合理 |
 | 6 earthyan 199 天前 方便回溯，不是挺好的吗 |
 | 7 javalaw2010 199 天前 合理。 不过如果团队规模较小，可以向负责人提出建议表示流程繁琐可以适当简化这个流程，小的 feature 或者 bugfix 可以在一个主干分支上完成。 |
 | 8 LotusChuan 199 天前 3 从你的描述来看挺合理的，建 issue 和建单独 branch 是耗时很久的操作吗？后续复盘的时候，issue 可以记录完整的开发过程；而用 git log 只能到时候 grep 一下，并且如果哪个人 log 没写关键词，他的 commit 基本找不到。很难想象 branch 都懒得建的人能写出多么规范的 commit message 。 |
 | 9 FukArtorias 199 天前 非常合理 |
 | 10 Lockroach 199 天前 几个人的小团队的话我个人感觉没啥必要，合理是合理的 |
 | 11 kakakakaka8889 199 天前 怎么不合理？我们还一个需求一个分支呢，bug 是 bug 分支，hotfix 是 hotfix 分支 |
 | 12 0littleboy OP 嗯，其实现在就我一个人开发这个 |
 | 13 ExplodingDragon 199 天前 |
 | 14 h1298841903 199 天前 可以考虑写一个指令，自动创建分支，以及名称。 |
 | 15 m1nm13 199 天前 3 过度设计,万恶之源,不论是代码上,还是流程管理上都是如此 |
 | 16 w568w 199 天前 多人开发非常合理。胡乱提交，等出问题或写日志的时候，就对着 commit 里一堆「 fix 、bug 、功能、a 、1 」哭去吧。 单人开发就随意了，可能 leader 有意要树立团队协作习惯。既然你之前从没接触过协作开发（否则也不会问出这种问题），我觉得学习一下挺好的，不用抵触。 |
 | 17 ckdxc 199 天前 看项目复杂程度吧, 如果是平台类或者只需要维护一个版本 master|main, 确实 git log 就能看完了 但是如果是多版本, 或者代码仓里面贼多模块, 有 issue 管理会稍好一些, 如果是更大的项目涉及多个仓库, 那 issue 可能也不好使了, 得用专门的管理软件 |
 | 18 lavvrence 199 天前 本来就应该这样，每个功能或 Bug 都要在单独的分支上实现。 哪个先实现好了随时合并到 代发布的生产分支 或者 测试用的分支。 |
 | 19 hyqCrystal 199 天前 其实 bug 解决完 要即使删除清理 这样做是合理的，不然的话 整个代码管理 看似用了规范，反而会导致更加混乱 |
 | 20 touchwithe 199 天前 via iPhone 合理 |
 | 21 xizh007 199 天前 很标准的流程 羡慕 |
 | 22 location123 199 天前 合理 好公司 |
 | 23 foolishcrab 199 天前 via iPhone 觉得不合理的时候想想你自己会不会在 commit msg 里写小作文介绍需求背景，代码设计。 你能做到的话公司要求把这些信息放到外部文档又能费多大事呢？ |
 | 24 Immunize 199 天前 多人开发的时候一般都是产品经理创建需求单/Bug 单，可以对应你这里的 issue 。然后你在一个独立分支上开发，发起 MR 的时候关联上，这样就能知道特定需求/Bug 的处理情况了，便于后续溯源。否则干了半年都不记得干了啥，为啥干了。 |
 | 25 dwu8555 199 天前 相当合理，不过一两个 dev 人员就没必要 |
 | 26 jiangxiaoshui 199 天前 1 个人不太合理，不过这样做也行。 只要 1 个人以上一定要用分支来管理，多人在一个分支操作出现对本身分支造成破坏性的操作就完了，在个人分支上出现这种操作也只是在这个分支，控制了影响范围。 |
 | 27 sparrowMan 199 天前 1 @0littleboy #12 非常合理，即使是你一个人开放，你能保证 fix 的、修改的 、新增的 都能按期上线吗？ 平时开发都是一个问题一个分支，然后根据进度和需求，挑选若干分支进行合并发版 |
 | 28 iugo 199 天前 如果是已知小问题并且没有建立 issue, 可以不建立 issue, 但至少要有 PR 及相关的分支吧. |
 | 29 kneo 199 天前 1 这叫项目管理。 |
 | 30 0xABCD 199 天前 via Android 合理，方便回溯当时做某个需求的背景 |
 | 31 guanzhangzhang 199 天前 2 看到好多人 commit 信息写 - fix - fix bug - fix build - update - test |
 | 32 35aZ4P8mT576683q 199 天前 首先合理，其次显得你工作量大 |
 | 33 momogzp 199 天前 合理, 其实一个人也是需要分支管理的. 有时候搞一个需求, 搞到一半, 有一个着急的 hotfix, 你不能就在需求分支上搞吧? 而且一个 issue 和一个分支对应也挺对的. 以后遇到同样的问题, 有 issue 跟踪, 还有 fix 的 commit. 想想以后要在上千个 commit 中找到某个 bugfix 得多难. |
 | 34 cumt21g 199 天前 非常合理, 理由上面的同学都说了 如果是一个人开发也合理, 有一天有人问起你这个地方为什么这么做,你可以把相关的 issue 链接甩给他,虽然繁琐,但是也是一种自我保护机制 |
 | 35 changnet 199 天前 每一个功能或 bug 都要新开一个 issue 我觉得是合理的。但一个 issue 一个分支这个理论上也合理，但操作太繁琐了吧，我从来没用过，需要切一个分支，后面还要合并。 |
 | 36 ldw2046 199 天前 必须合理啊，项目稍微复杂点，不这样弄，代码会成屎山代码。 |
| 37 ldw2046 199 天前 @hyqCrystal gitlab merge 到主干的时候默认删分支，所以其实还好，看着很清爽 |
 | 38 davin 199 天前 git 提交时，可以跟一些第三方协作工具的 webhook 合作，直接链接到对应 issue ，撕逼的时候方便看到原因 |
 | 39 cccvno1 199 天前 1 只要是公司项目这样都合理，开发的代码属于公司资产，完备明确的流程是公司对自己资产的保护。比如一些稳定运行了很多年没有变更的项目，要有新的功能变动，当时的开发者可能已经离职了，没离职也不能有多深的记忆，这时候这些 issue 的价值就体现出来了。 既然公司规定了就好好执行（又不是什么脑残规定），大项目遵守、小项目不遵守到最后肯定就都是一地鸡毛，git log 都不见得好好写了，所以口子一点不能松。 |
 | 40 xubingok 199 天前 不合理...需求和 bug 可以单开分支,定期合并. 没有必要为每一个需求甚至每一个 bug 单独开分支. new branch>commit>merge>delete branch.真是吃饱了撑得. |
 | 41 harlen 199 天前 我同事就喜欢在主分支上干事，没次他有 bug 整个项目组都得等他把 bug 修复好，才能正常开发，光明正大的摸鱼，最后结果裁员的时候，就他没被裁 |
 | 42 sexyback 199 天前 就去过两家公司，都是这么做的，我觉得挺合理的，无非是分支切换麻烦一些 |
 | 43 Valpha6 199 天前 用分支管理或者用 git comment 管理都有道理，主要看分支策略。单主分支瀑布交付用 git log + 模板约束一样可以实现管理和质量的诉求。多人合作且对过程版本有要求，那建 issue 分支同样重要。都是合理的流程，要看公司的质量要求如何 |
table cellpadding="0" cellspacing="0" border="0" width="100%"> 
44
guiyumin 199 天前 via iPhone Too young
 | 45 timeance 199 天前 等你年度汇报的时候就发现能一键统计工作量太有用了 |
 | 46 kermitlee 199 天前 合理，羡慕+1 |
 | 47 donaldturinglee 199 天前 via Android 大项目的 git log 非常的长，除非需要审查，一般都不怎么看。 我修 bug 是新建一个临时的 fix bug 分支，然后在 commit 里面对应 issue 的 id ，最后再把 fix bug 分支删了 |
 | 48 v1 199 天前 朋友公司十几年的 smb+版本 zip+readme.txt ，20 多人团队，没出过问题，所以用什么无所谓，关键是大家都能接受 |
 | 49 myderr 199 天前 我还想要这种管理呢，我们现在十来个人都在 master 上一把挫 |
 | 50 zacard 199 天前 合理。项目越复杂，协作人越多，好处越多 |
 | 51 picone 199 天前 合理。 除非你 git log 能把详细的上下文贴上去，不然的话在 PR 上加上，一般都做不到，Issue 是最保底的方式。不然几年后别人接盘你的代码不知道你为什么改 |
 | 52 Int100 199 天前 via iPhone 合理。请养成好习惯。 |
 | 53 punkerhyde 199 天前 2 你不想标准，你以后工作当中碰到不标准的也不要叫，就是这样 |
 | 54 NealLason 199 天前 非常合理！ |
 | 55 NoManPlay 199 天前 可以了解一下 git flow |
 | 56 shiny 199 天前 几年后你在不在公司都不知道，接手的人看 issue 和看 git log 哪个容易 |
 | 57 msg7086 199 天前 1 个人开发的话不合理，几十个人的大组开发的话这是基本要求。 我们不光每个工作要开 Jira ，并且每个更改都需要写 Confluence Page ，把修改案、测试用例和测试结果都写在里面。万一程序发出去了出了问题，都有文档可以查证复盘，做了哪些工作，哪些漏了以后需要改进，等等。 反正我带薪写 issue 带薪建分支，又没亏待我。 |
| 58 msg7086 199 天前 1 当然你要说你有本事把流程图和需求和测试全部写在 commit message 里那我敬你是条汉子。 |
 | &nbs; 59 iyaozhen 199 天前 合理 大公司都这样（不是说大公司一定是对的 一般来说工作都是面向 issue （或者类似的），分支倒没有强制，但一般项目系统都给你分支拉好了。 就是你的所有开发工作（新需求+bugfix ）都是要 issue ，就是你不能打黑工（即使你是技术调研都需要建一个子任务），这样方方面面才有迹可循。测试也是一样手工 case 、提的 bug 都需要关联起来 |
 | 60 adoal 199 天前 开一休是处理具体问题的前置事件，看老哥则是后置事件。 |
 | 61 DamonLin 199 天前 合理，之前在 10 个人的开发团队就是这样的，切换新的分支 issue 让大家都知道到底在干什么，追溯问题也非常容易，开发组长在合并 master 就知道每个分支具体在操作哪块代码。 |
 | 62 AoEiuV020JP 199 天前 如果这项目只有两三个人开发，搞那么多分支不大合理，还不如要改什么喊一声， |
 | 63 NewMoorj 199 天前 合理，有外企风格，蚂蚁虽小五脏俱全，只有流程管理到位了，才不会出现那种半夜喊你起来，或者休假中 call 你的事 |
 | 64 q2677855779 199 天前 合理的，git 分支不就是给你做这个的嘛，专门的分支搞专门的事情，上面也兄弟说的好，你改着改着，要做其他紧急的需求或者 bug 咋办？ |
 | 65 cyrivlclth 199 天前 @AoEiuV020JP 确实，两三个人的话，为了防止有冲突，自己要推送的时候让别人不要开发，避免冲突 [狗头] |
 | 66 wysnxzm 199 天前 想省事不按规则来那就要接受解决非常规问题付出的更多成本,每一条规则的背后都是经验教训 |
 | 68 dumbass 199 天前 公司项目也只我一个人维护，开发新需求我都会 git flow feature start 一下 |
 | 69 gefranks 199 天前 via iPhone 很合理, 这样的流程是在保护你. 确保改动都有记录, 代码和 git log 一般只有开发用 但 release 一个功能, 修一个 bug 参与的人上下都有很多 不要在改一个东西的代码里夹带其他的改动. 之前公司里有这个流程, 但是开发不遵守,时不时的夹带其他的改动, 然后出过好些次线上的大小问题 现在大部分都老实了. |
 | 70 wzzyj8 199 天前 1 1. 合理 2. 你不能假设所有的人在同一个公司+同一个组永远待着，所以你需要有 jira backlog 3. 最重要的事情应该被先完成，也就是哪怕有一个简单的 bug ，如果优先级低，不应该在随机的一个 PR 里和别的 feature 混在一起修复。这样做最大的问题是 release/rollout 会有困难，同时增加 oncall 追踪问题的负担。出现需要滚回的情况会发现依托答辩根本不知道哪里的问题。 |
 | 71 houshuu 199 天前 via iPhone 不分开要是一个功能挂了你想单独拎出来 rollback 还得去看 commit ？风险太大了，说不定还得解决 conflict 以前做过没有 blue green deploy 的项目，rollback 完成前的每秒钟都在造成巨额损失，能快一点就是一点。分开来至少直接 rollback 一个 squash merge 的 commit （ pr ）就行 |
 | 72 qinxi 199 天前 7 对比一下. 你喜欢哪一种?   |
 | 73 DinnyXu 199 天前 首先你不要站在开发的角度思考问题，一个流程完善的公司，比如我们是这样操作的，我们在首次提测后，如果有新功能 A 开发，同时也有 bugB 要解决，我们会提供 ai-ocr/-/tags/1.1.1_T20250326_1 , 这个里面有新功能 A ，但是 bug B 我正在修改，所以代码不在其中，如果我 bugB 也修改完了，我会再打一个类似的 TAG ，这样做的的是测试在执行用例的时候如果系统报错阻塞了，测试能够第一时间根据 TAG 回滚到上一个版本，不至于影响他接下来的测试 |
 | 74 yb2313 199 天前 真写在一块了你又要哭 |
 | 75 xz410236056 199 天前 @sparrowMan 说不定明天公司都没了，别在这过度设计了哥。 |
 | 76 337136897 199 天前 相当合理 |
 | 77 Aqued 199 天前 合理，因为有的需求做的做的可能就没了，你都放在一起后面摘都费劲， 还有将来出了问题 可以根据 commit 信息追溯到分支 并且追溯到任务 |
 | 78 hefish 199 天前 我觉得 op 说的很对，完全不需要那么多 issue ， 一个项目只需要一个 issue 就可以了。 |
 | 79 Scarb 199 天前 合理啊，git log 只写改动，但是没有为什么要改之类的背景，以及改动设计、测试结果等等。这些都可以写在 issue 里。 不然很容易就不记得一个地方为什么这么改了 |
 | 80 mxT52CRuqR6o5 199 天前 比如提了个一个 bug 的 issue 单，但最后发现是 feature 不进行代码提交，这种场景你准备杂用 git log 的方式去做？ |
 | 81 htxy1985 199 天前 从管理角度当然很合理，但在效率上是灾难，更别提还有别的指标，具体如何平衡完全看此项目的上下文场景。 |
| 82 mxT52CRuqR6o5 199 天前 git log 就代表只有开发能参与到其中，产品、测试、设计都没法参与了 |
 | 83 wqq096737ink 199 天前 当然合理了, 出了问题好追责,免得跟这种人扯皮 |
 | 84 linzyjx 199 天前 非常合理，要不然怎么算工作量（ x 真要说每个 issue 要填工时的。 就两三个人的小团队可以把颗粒度调高一些，比如一些功能添加可以搞，一些真的很小的就看情况。 具体就可以看一下 gitlab 的实践了 |
 | 86 oops1900 199 天前 很合理呢，不同分支解决的问题都可以部署测试。互不干扰。公司这是让你有良好的习惯。 |
 | 87 volantRookie 199 天前 相当合理 |
 | 88 peeves 199 天前 等需求没沟通（设计）好需要扯皮、需要分锅的时候你就知道合不合理了 |
 | 89 yangyaofei 199 天前 合理不合理看是什么样的项目, 多少人维护, 有没有自动化的测试. 原来我也觉得这样是对的(绝对正确的那种), 但是要是就 3 人精力有限, 还前期经常改动 bug 无数需求无数 的时候, 这样做就变成政治正确了. 个人觉得: 1. 人少的时候能保证单个提交是一个 issue 就很不错了 2. 经常改动的时候, 逻辑上一起的东西一块提交就行了 有无限的人力和无限长的 deadline 另算, 优雅和漂亮是有成本的, 在有限的时间和精力下尽量优雅就算可以了.有些人真的是连内容都不看就喷啊 |
 | 90 eijnix 199 天前 你这算啥，我们这改任何代码都要建立对应的 jira 单的，tech, feature, bug 。 并且 git hook 的 pre commit 要从 branch 名提取单号，注入到 commit msg 里。 好处就是之后看问题很方便，之后看这行代码就能从 jira 里追溯到当时为什么要改这里。 |
 | 91 iguess 199 天前 合理，但你一个人，那就不合适。 |
 | 92 cnhbwhm 199 天前 我觉得需求可以一个 需求 一个 单独的工单， 但是如果只是简单的 bug 修复 ，我觉得没必要 |
 | 93 17681880207 199 天前 意思是每次 commit 只解决一个 bug 或者 feature 嘛？ |
 | 94 Rickkkkkkk 199 天前 你可以把你感觉不合理的点以及改进方案整理一下，然后组里分享。 如果提的确实有道理，会改的。 |
 | 95 zephyru 199 天前 你问合不合理那肯定是合理的。 但你问合不合适，那就是看情况了。 如果 bug 和需求可以单独上线，基本是要单独拉分支的，方便管理。 你不能保证哪个会先要或者后要还是一起上线。 你如果能保证就是一起上板上钉钉，绝对不会改，混在一起问题也不大，不过看这架势拍板的估计也不是你... |
 | 96 duanzhanling 199 天前 非常合理 |
 | 97 hegfirose 199 天前 项目里写个简单的脚本，把建 issue 和建分支的工作同时做了就好了 |
 | 98 Chuckle 199 天前 合理啊，标准流程，内部工单系统，一个工单对应一个新功能需求，然后内部流水线系统能管理分支和工单，写完推送就自动部署测试环境。 |
 | 99 kneep 199 天前 不但合理，而且我们要求每个 commit msg 都要关联票号，没票不允许提交代码。双向追溯。 |
 | 100 icanfork 199 天前 应该从程序上限制你不关联 issue 单号就不允许你提交 commit 才合理 |
Select Language