如何在Bitbucket中实现Partial Checkout？生产迁移分支方案咨询

你之前直接从development分支创建release分支的操作，会让release天然继承development上所有未上线的开发历史，必然会带入多团队的全部开发内容，没法做到只保留需要上线的少量作业。核心调整思路是把release的基线从development换成当前生产环境运行的master版本，再把需要的改动精准挂到这个干净基线上，操作步骤如下：

1. 清空现有release分支上从development带过来的无关内容，让分支和当前线上版本完全对齐
   • 切到本地release分支：git checkout release
   • 硬重置分支到和远端生产master完全一致的状态：git reset --hard origin/master
   • 把重置后的分支推到Bitbucket远端，覆盖之前带了全量开发内容的旧版本：git push origin release --force-with-lease
2. 精准把需要迁移的少量作业改动同步到干净的release分支，两种适配不同场景的操作方式：
   • 如果待迁移的作业在development上已经拆成了独立提交（每个作业对应明确的commit哈希值），直接用git cherry-pick把目标提交摘过来，完全不会带入其他无关开发内容：git cherry-pick <commit-hash-1> <commit-hash-2> ...
   • 如果待迁移的作业是独立的目录/文件单元，直接从development分支精准拉取对应路径的文件到release分支，完成后提交即可：git checkout origin/development -- path/to/target/job1 path/to/target/job2
3. 所有需要上线的改动调整完成后，在预发环境跑完全流程验证，直接把这个干净的release分支合并到master即可。此时master收到的改动将完全是你选定的生产作业内容，不会混入其他团队的未上线开发工作。

• 所有生产类分支的起点必须对齐线上状态：不管是常规发布的release分支，还是紧急修复的hotfix分支，永远从当前最新的master（线上实际运行版本）切出，禁止直接从多团队共用的development分支拉生产相关分支，从源头避免未验证的开发内容进入生产链路。
• 坚持小粒度、可追溯的变更迁移：不管待上线的改动工作量多少，都通过cherry-pick、精准文件拉取的方式同步到生产分支，不要为了图省事直接把development全量合并到master。哪怕development当前状态看起来稳定，混在其中的其他团队未完成开发内容随时可能引发生产故障。
• 保持release分支的临时性：release分支仅承载单次发布周期内需要上线的内容，发布完成、合并到master后就及时删除，不要长期复用同一个release分支积累多轮发布的内容。下次发布时基于最新的master切全新的干净release，避免新旧内容混杂。
• 用权限规则做硬隔离：给master分支设置保护规则，禁止直接提交、直接合并development分支的PR，所有进入master的改动必须经过独立release分支的预发验证、代码评审环节，从流程上堵住误操作的风险。
• 日常开发时保持提交粒度清晰：在development分支开发时，每个独立作业的改动尽量拆成独立的、可单独迁移的commit，不要把多个不相关的作业、多个团队的改动揉在同一个大提交里，避免后续生产迁移时没法精准筛选需要的内容。

内容的提问来源于stack exchange，提问作者Vipendra Singh