公司每一个功能或 bug 都要新开一个 issue,合理吗
比如我要开发一个新功能 A 和解决一个 bug B
就需要建立 issueA ,issueB
然后根据 issue 编号建立,如分支 t_32 解决 issueA ,t_33 解决 issueB
这种方式合理吗?
我感觉很麻烦,明明通过 git log 就能区分的事情,需要额外做挺多事
而且这个项目也没几个人开发
合理,为什么不合理,你刚毕业吗?
非常合理,谁没事干看 log 去
合理个 der
合理,标准的开源流程
合理
方便回溯,不是挺好的吗
合理。
不过如果团队规模较小,可以向负责人提出建议表示流程繁琐可以适当简化这个流程,小的 feature 或者 bugfix 可以在一个主干分支上完成。
从你的描述来看挺合理的,建 issue 和建单独 branch 是耗时很久的操作吗?后续复盘的时候,issue 可以记录完整的开发过程;而用 git log 只能到时候 grep 一下,并且如果哪个人 log 没写关键词,他的 commit 基本找不到。很难想象 branch 都懒得建的人能写出多么规范的 commit message 。
非常合理
几个人的小团队的话我个人感觉没啥必要,合理是合理的
怎么不合理?我们还一个需求一个分支呢,bug 是 bug 分支,hotfix 是 hotfix 分支
嗯,其实现在就我一个人开发这个
嗯,其实现在就我一个人开发这个
不是协作开发没必要,如果不用汇报的话那就更没必要了
可以考虑写一个指令,自动创建分支,以及名称。
过度设计,万恶之源,不论是代码上,还是流程管理上都是如此
多人开发非常合理。胡乱提交,等出问题或写日志的时候,就对着 commit 里一堆「 fix 、bug 、功能、a 、1 」哭去吧。
单人开发就随意了,可能 leader 有意要树立团队协作习惯。既然你之前从没接触过协作开发(否则也不会问出这种问题),我觉得学习一下挺好的,不用抵触。
看项目复杂程度吧, 如果是平台类或者只需要维护一个版本 master|main, 确实 git log 就能看完了
但是如果是多版本, 或者代码仓里面贼多模块, 有 issue 管理会稍好一些, 如果是更大的项目涉及多个仓库, 那 issue 可能也不好使了, 得用专门的管理软件
本来就应该这样,每个功能或 Bug 都要在单独的分支上实现。
哪个先实现好了随时合并到 代发布的生产分支 或者 测试用的分支。
其实 bug 解决完 要即使删除清理 这样做是合理的,不然的话 整个代码管理 看似用了规范,反而会导致更加混乱
合理
很标准的流程 羡慕
合理 好公司
觉得不合理的时候想想你自己会不会在 commit msg 里写小作文介绍需求背景,代码设计。
你能做到的话公司要求把这些信息放到外部文档又能费多大事呢?
多人开发的时候一般都是产品经理创建需求单/Bug 单,可以对应你这里的 issue 。然后你在一个独立分支上开发,发起 MR 的时候关联上,这样就能知道特定需求/Bug 的处理情况了,便于后续溯源。否则干了半年都不记得干了啥,为啥干了。
最近双 11 好多应用一不小心就会跳到淘宝,很烦,弄了一个屏蔽摇一摇的 xp 模块 只需要勾选需要屏蔽的应用即可生效 开源地址: github.com/pwh-pwh/fuc…
对这些银行业务不大熟。 双币卡是只有信用卡,没有储蓄卡的对吧? 如果要申请,哪家银行的比较好?我对信用卡权益啥的完全不了解。 因为双币卡是信用卡,所以同一家银行下也有不同类型的…
如题。最近准备自己折腾个 NAS ,但是相比普通的方案,有一些特别的需求: 体积最好小一些,便携(可能要经常带出去);因为要放在宿舍 7*24 运行希望噪声也小一些,不要打扰…