jerryzhou343 最近的时间轴更新 jerryzhou343 最近的时间轴更新 |
jerryzhou343V2EX 第 490714 号会员，加入于 2020-05-21 14:52:55 +08:00 |
jerryzhou343 最近回复了
2021-02-05 09:18:00 +08:00 回复了 lvwzhen 创建的主题 › 分享创造 › [回复参与抽奖] Clubhouse 头像生成器首发 |
分子
2020-12-22 09:37:38 +08:00 回复了 simonlu9 创建的主题 › 程序员 › gitflow 在实践中的一些疑问 |
@simonlu9 每个分支都有自己的角色（责任）和生命周期，所以不用纠结你的流程一定要遵循 gitflow，你可以定义自己的 xxx 流程；
回复第一点：这个描述下，这个流程中有 feature , release, test, master，dev ; 在这个模式下，如果团队对提交干净整洁度没有洁癖的话，test，dev 分支就没啥用了。到测试时间点的时候，拉 release，然后合并测试，测试 ok 直接上 release ；如果你们有提交整洁度要求，那可以用 test-xxx 这样的分支来做初次汇聚，测试完成； feature 提交做 rebase，然后再拉 release 合并发布；
回复第二点：基于上一次发布拉出 fix-xxx 分支，修复完成；看发布计划，如果是紧急重要，这个 bug fix 提前单独 release 出去；如果不紧急重要，就跟着发布计划，合并到 test 测试，跟着需求上线；
回复第三点：feature 分支的内容并不一定需要马上合并到 test 的，也许只是开发人员同步代码的时候一次提交，并不想合并，所以这里不建议做自动化；
回复第四点： 分支存在的理由是它有自己的角色和职责；先有需求，才有了对应的分支，不要陷入固定的思维，可以问下自己，gitflow 为什么有 dev 分支；
回复第五点：公共部分代码是不是可以认为是 featureC 呢；如果没有公共部分，featureA，featureB 就无法进行下去；那么可以先做好公共部分再启动 featureA，featureB 的开发；或者三个分支独立，featureA，featureB 先依赖一个接口，然后在测试的是汇聚；或者 featureA,featureB 合并为一个需求,一起开发；（公共部分代码在这个情况下也是不稳定的，featureA,featureB 贸然合入，并不一定是好的选择)
回复第一点：这个描述下，这个流程中有 feature , release, test, master，dev ; 在这个模式下，如果团队对提交干净整洁度没有洁癖的话，test，dev 分支就没啥用了。到测试时间点的时候，拉 release，然后合并测试，测试 ok 直接上 release ；如果你们有提交整洁度要求，那可以用 test-xxx 这样的分支来做初次汇聚，测试完成； feature 提交做 rebase，然后再拉 release 合并发布；
回复第二点：基于上一次发布拉出 fix-xxx 分支，修复完成；看发布计划，如果是紧急重要，这个 bug fix 提前单独 release 出去；如果不紧急重要，就跟着发布计划，合并到 test 测试，跟着需求上线；
回复第三点：feature 分支的内容并不一定需要马上合并到 test 的，也许只是开发人员同步代码的时候一次提交，并不想合并，所以这里不建议做自动化；
回复第四点： 分支存在的理由是它有自己的角色和职责；先有需求，才有了对应的分支，不要陷入固定的思维，可以问下自己，gitflow 为什么有 dev 分支；
回复第五点：公共部分代码是不是可以认为是 featureC 呢；如果没有公共部分，featureA，featureB 就无法进行下去；那么可以先做好公共部分再启动 featureA，featureB 的开发；或者三个分支独立，featureA，featureB 先依赖一个接口，然后在测试的是汇聚；或者 featureA,featureB 合并为一个需求,一起开发；（公共部分代码在这个情况下也是不稳定的，featureA,featureB 贸然合入，并不一定是好的选择)
2020-12-17 20:07:49 +08:00 回复了 simonlu9 创建的主题 › 程序员 › gitflow 在实践中的一些疑问 |
@simonlu9 接上条回复。每个分支的职责其实需要根据你们的开发流程来定的；如果你们走的瀑布模式的流程；在 dev 分支修复 bug 是没问题的；如果你们走的敏捷迭代模式，最好不好在 dev 上修 bug ；因为在 sprint 中，某个 feature 可能赶不上时间点；所以建议的是不要在 dev 上修 bug ；不然 cherry-pick 有时候也挺麻烦的； feature 分支提交记录多用 rebase，这样可以让提交记录清晰，并且不会太多；
2020-12-17 20:00:40 +08:00 回复了 simonlu9 创建的主题 › 程序员 › gitflow 在实践中的一些疑问 |
@simonlu9 每个分支都有自己的角色（责任）和生命周期； dev 分支作为 feature 的汇聚分支，合并其他 feature 就是其责任，所以 dev 不存在污染一说； feature 有 bug，在对应 feature 修改，然后再合并到 dev ；如果有 bug 直接在 dev 修，那才是污染 dev 分支了，让 dev 承担了开发的职责；
2020-12-17 16:03:25 +08:00 回复了 simonlu9 创建的主题 › 程序员 › gitflow 在实践中的一些疑问 |
修正下命令:cherry-pick
2020-12-17 16:02:06 +08:00 回复了 simonlu9 创建的主题 › 程序员 › gitflow 在实践中的一些疑问 |
1. a,b 在各自分支修的 bug ；那么丢弃 dev，重新基于上一次 release 拉一个 dev，然后将 a 合并到新的 dev ；
2. a,b 在修 bug 的时候是在 dev 修的。通过 pick-cherry 将 a 的提交挑出来合并到 a，然后基于上一次 release 重新拉一个 dev，将 a 合并到新的 dev ；
2. a,b 在修 bug 的时候是在 dev 修的。通过 pick-cherry 将 a 的提交挑出来合并到 a，然后基于上一次 release 重新拉一个 dev，将 a 合并到新的 dev ；
Select Language