 |
1
sadfQED2 Apr 21, 2022 via Android
第一次见到有 fork 到个人仓这种流程😂直接在主仓建 dev 分支有啥问题吗？
|
 |
2
jasondennis12139 OP @sadfQED2 在主仓每人都建一个 dev 分支？二三十个个人的 dev 分支很难管理啊
|
|
3
sadfQED2 Apr 21, 2022 via Android
@jasondennis12139 为啥难管理，你们要管理啥？我们项目都是上千个分支啊
主仓库 release 分支是线上代码 Master 分支是待上线代码 Test 是测试代码 这三个分支开启 merge 保护，不能随意合代码进去，其他分支都随便玩 |
 |
4
ccyu220 Apr 21, 2022
@jasondennis12139
个人认为：公司项目就不需要像 GitHub 上那样先 fork 再分支的流程。 如同 1# 说的一样，每个功能在主仓建立一个分支，开发根据需求再自己本地分支就好了。 如果有公共文件修改，那就再分支一个需求，merge 之后各人再拉取。 dev 全部开发合并完成之后主分支再按版本合并。 --- 综上，不知是否有我还未认知的利弊？我也想学习下其他人的流程是如何。 |
|
5
sadfQED2 Apr 21, 2022 via Android
我们是主仓每个需求建一个分支
|
 |
6
MoYi123 Apr 21, 2022
@jasondennis12139 分支肯定不是按人建, 而是按功能建啊.
|
 |
7
Jooooooooo Apr 21, 2022
组内互相了解大家的需求大致的改动啊, 如果有改动同一处功能得提前沟通.
不过你们啥东西需要开发 3 个月? 拆小分开上呗. |
 |
8
starerlloll Apr 21, 2022  1
我觉得主要问题是 3-4 个月才合并一次代码。。这频率太低了。。。还有 20 多个开发，，
|
 |
9
GeruzoniAnsasu Apr 21, 2022
PLEASE （大写强调） 最长周期 一周
合一次代码 开发周期和代码同步周期完全是两回事，代码同步频率拉起来你遇到的依赖问题全都不存在了 啊，你说没写完同步代码没意义，所以为什么不把任务拆细一点每个可以跑的单元都尽可能小呢，这不就「敏捷」起来了 |
 |
10
securityCoding Apr 21, 2022 via Android
@sadfQED2 大仓模式下都在主库搞分支不现实的。
|
 |
11
laozhoubuluo Apr 21, 2022 2
1. 一个开发团队开发一个新功能开发周期 3 - 4 个月说明软件架构有严重问题，绝大多数项目和公司根本接受不了这个周期。建议需求规划端做合理拆分，单个需求用 4 个月不如拆成 20 个需求每个一周会更合理。如果没法拆分那也没办法，说明软件架构积重难返了，如果您不是给金融行业写 COBOL 的工作建议尽快转行。
2. 如果确实积重难返的话也有办法缓解，如果一个需求 7 天之内做不完，那么每周需要找一天 rebase 每个需求的 dev 仓库，保证当时 dev 仓库的内容是主线 Dev 仓库 + 新增内容，可以保证合并期间不那么折腾，相当于牺牲开发进度保证最后合并成功率。 |
 |
12
wd Apr 21, 2022 via iPhone 1
你需要的恐怕是多花点钱雇几个靠谱的人...
|
 |
13
zpxshl Apr 21, 2022 via Android
我们主仓几万条分支，还有大量子仓，同样分支爆炸
|
 |
14
FranzKafka95 Apr 21, 2022 via Android
功能开发三四个月不代表你三四个月提交一次吧，更新一点就提交到远程主仓，其他同事及时更新后 merge 到本地个人分支，大家都这样操作就行了
|
 |
15
Building Apr 21, 2022
这就是为什么项目同一个功能的函数能出现好几个的原因，为了方便都手写了一个 private 的给自己专用
|
 |
16
cutepig Apr 21, 2022 via Android
我们这边有类似的问题，我们总结原因在于软件设计不好。模块化做的不好。code review 不够。代码修改太随意。
我们正在通过 pull request 做 code review ，希望能够改善情况 仅供参考 |
|
17
jasondennis12139 OP @starerlloll 肯定不是 3 个月才合一次，是一个很大的新增需求，覆盖了几乎所有模块，并且直接催生了一个新的微服务。期间不停的在向开发分支提交代码，也定期 merge 到测试分支。但是在大范围提发布到发布分支的时候出了问题。
|
 |
18
mozhizhu Apr 21, 2022
AB 相互依赖部分抽离出来，做 Base ，每次变化都基于 Base 修改（开发阶段支持 A 、B 单独调用），Base 及时进行测试和内部发布；尽量不要因为 AB 同改，最后合并爆炸
|
 |
19
Huozy Apr 21, 2022 1
不建议 fork 到个人仓。
假定 Master 分支为生产版本代码，测试环境分支 test ，验证环境分支 UAT 。生产发布周期为 7 天一次。 Master 、UAT 、test 分支均受保护，普通开发无法直接提交或合并。 需求 A 从 Master 分支切出一个 dev_A ，需求 B 从 Master 切出 dev_B ，dev*分支都是由开发个人维护的，做相应需求开发。 dev*分支在开发过程中应在每个上线周期后与 mater 进行同步。 开发完成后，发起合并请求至 test ，上测试。由专人进行合并管理解决冲突。 假定上线日为 T 日，那么在 T-7 日时，应将已经测试完成的 dev_A ，由专人合并至 UAT 分支，发布进行验证测试。完成后将 UAT T-7 日版本 打包进入待上线，T 日发布。 发布成功后，T+1 日将 UAT 分支合并至 Master 分支，并打上 tag 。 假设 T+2 日，发现重大 BUG ，应从 Master 分支切出 BugFix 分支修复，并直接合并至 UAT 分支进行测试验证再发布。 理论上来说，test 分支上的 feature 功能不会与 UAT 同步，即某些功能上了测试，但可能最终都不会正式发布，那么此时 test 分支已经与 Master/UAT 相差较远，所以 test 分支应该定期删除，重新从 Master 分支切出，再将 dev*合入 test 分支进行测试。 上了 UAT 分支的代码，一定是要发布至生产的，如不发布，需要回退 UAT 分支。 如果你的 A 需求与其他需求代码出现大量冲突或者大量依赖的，需要团队负责人对开发周期进行考量和调整。 git 工作流没有办法完全解决代码冲突，只是尽可能的减少冲突出现。 |
 |
20
dlsflh Apr 21, 2022
大家好，请问楼上这些知识看什么书能获得？
|
 |
21
duke807 Apr 22, 2022 via Android
建議用 gerrit ，不需要 fork 到個人倉，主庫也不會分支爆炸，多人研發同步進度也及時
|
Select Language