基于Trunk based分支策略，Azure Repos未完成功能与发布管理问询

问题1：每日向main提交变更时，未完成feature分支的管理及替代方案 #

未完成feature的管理最佳实践 #

• 拆分功能为可提交的小单元：把大feature拆成多个不破坏现有系统的小模块，每天提交一个可独立运行的模块到main。比如开发用户头像上传功能，先提交基础的文件上传接口（空实现但能通过CI），再逐步补文件校验、存储逻辑，每次提交都保证main分支可正常构建运行。
• 每日合并feature分支的可运行部分：如果feature暂时无法拆分，在feature分支开发时，每天将已完成的、可通过CI的代码片段cherry-pick到main，或者rebase feature分支到最新main后，合并一小部分稳定代码。这样既满足每日提交要求，又不会把未完成的整块代码丢进main。
• 隐藏未完成功能：把未完成的代码放在不对外暴露的逻辑里，比如后台接口写好但不添加到路由配置，前端组件开发完成但不在页面中渲染，确保提交到main的代码不会被用户或其他业务逻辑触发。

Feature Toggle之外的替代方案 #

• 短期临时分支隔离：不长期保留feature分支，而是每天结束时，把未完成的代码留在feature分支，第二天先将feature分支里已完成的部分合并到main，再继续开发。注意要频繁将main的最新代码合并到feature分支，避免冲突积累。
• 抽象层占位法：针对需要重构或新增的复杂功能，先定义好抽象接口，用现有逻辑实现接口保证系统正常运行，再逐步替换为新功能的实现。每次提交都是基于抽象层的可运行代码，直到新功能完全完成后再切换到新实现。
• TODO标记+受控提交：针对极小的未完成代码片段（比如某个函数的参数校验未写完），用// TODO: 完善参数校验标记后提交到main，但必须保证这段代码不会被调用或影响现有功能。这种方法只适合小改动，避免长期积累技术债。

问题2：main分支含未完成功能时，创建仅包含完整功能的release分支 #

• 基于历史完整提交点创建：找到main分支上最后一个所有功能都处于完成状态的提交哈希值，执行命令：

  git checkout -b release/v1.0.0 <完整提交的哈希值>
  

  后续如果有新的完整功能需要加入release分支，直接cherry-pick对应的提交即可。
• 反向撤销未完成功能：先从main分支创建release分支，然后用git revert命令撤销所有对应未完成功能的提交。比如未完成功能对应提交哈希是abc123，执行：

  git revert abc123
  

  这种方式不会修改历史，适合代码已推送到远程仓库的场景。
• 提前标记完整功能提交：在开发过程中，给每个完整功能的最终提交打标签，比如：

  git tag feature-complete/user-profile
  

  创建release分支时，基于最近的几个完整功能标签的合并点，或者逐个cherry-pick这些标签对应的提交，确保release分支只包含已完成的功能。
• Azure Repos拉取请求辅助调整：先创建release分支，然后通过Azure Repos的拉取请求，将main分支中已完成的功能提交合并到release分支；如果main中有未完成的功能，也可以通过拉取请求将release分支中对应的撤销提交合并回去，或者直接在release分支中手动revert相关提交。

内容的提问来源于stack exchange，提问作者Saurabh khandelwal