AngusGit 适合哪些团队、用在什么场景？日常协作、合并发布和交付审计时分别怎么用？
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
AngusGit 适合需要把代码留在自己服务器上的团队，主要用在三个时刻。日常协作时，在内网搭一套代码托管和评审，把需求、议题和代码改动串起来。合并和发布前，用分支保护和安全检查拦住有问题的改动，用流水线完成构建和发布。交付和审计时，用代码溯源查清代码来源，用操作记录回看每一次改动。
下面分别说怎么做。
适合源码和评审记录不能放到公有云上的团队。
AngusGit 部署好之后，成员用统一门户 AngusGM 的账号登录，就可以建仓库、提合并请求、做人工评审。原来在其他平台上的仓库，可以批量导入 Git 历史，再按需整理议题和保护规则。之后用测试、制品和安全检查时，也是这套账号，不用每个系统各开一次。
评审时，可以用 CODEOWNERS 指定某块代码必须由谁来审，也可以让 AI 先逐行给出建议，帮评审人更快看完。
适合需求多、经常要回头查「这个改动是为了哪个需求」的团队。
需求和缺陷记成议题，挂上标签、指派人和里程碑。开发提交合并请求时，在描述里写上 #编号，议题和代码改动就能互相跳转。需求的设计说明和接入文档放在仓库 Wiki 里。这样过几个月再回头看，从议题点进去就能找到当时改了哪些代码、谁审的。
适合希望问题在进入主分支之前就被发现的团队。
先把主分支设成保护分支：禁止直接推送，合并前需要人工通过。再在「管理」里接上 AngusSecurity。保护规则打开「要求安全检查通过」，仓库再打开「未通过时拒绝合并」，未通过的改动才合不进去。还没扫描过，先别当成没有问题。
可以先提交一个带测试密钥的改动试一次，确认它会被拦下。
适合希望构建、发布和代码在同一个地方管理的团队。
在仓库里提交一份 .anguscicd.yaml，推送后就会自动构建和测试；不想手写，也可以让 AI 先起草一份，确认后再启用。要让失败挡住合并，把状态检查里的名字写进「必需的状态检查上下文」。名单空着时，页面上的失败不会拦住合并。用任务依赖把构建、预发和生产串起来，生产前挂一个审批，到时候由负责人在「审批」里点通过。执行任务的机器叫运行器，登记之后用标签分配任务。构建失败时，AI 可以读日志给出排查方向。
这样，流水线的密钥、审批记录和运行历史都跟着仓库权限走，能看代码的人才能看到对应的构建。
适合需要在项目交付、外包验收或内部审计前确认代码来源的团队。
打开侧栏「溯源」，按仓库、文件、代码块或函数发起相似度对比，就能找出大段重复或来源相同的代码。结果可以对比和导出报告，作为交付或审计材料。需要回看某个仓库的历史操作时，到「活动」里按类型查谁在什么时候做了什么。
不用一次把所有功能都用上，可以按四步慢慢扩展。
.anguscicd.yaml，让推送自动构建和测试，生产发布挂上审批。每个菜单的用途见同系列「AngusGit 支持哪些功能」。
文档：https://www.anguskit.com/zh/docs/git
产品页：https://www.anguskit.com/zh/products/git
评估：https://www.anguskit.com/zh/contact/
AngusGit 适合中大型研发团队及合规敏感型项目，覆盖代码托管、协作评审与交付审计全流程。
日常协作中，开发者基于特性分支开发，通过 MR/PR 发起评审，结合行级评论、AI 辅助审查和自动化检查，确保代码质量；支持多人并行开发与冲突预警，减少沟通成本。
合并发布时，主干受保护策略约束，必须通过 CI 流水线、安全扫描及至少两人批准才可合入；标签与发布说明自动生成，关联需求与缺陷，保障版本可追溯。
交付审计阶段，完整保留提交历史、评审记录、权限变更及操作日志，支持按时间、人员或文件维度导出报告；满足等保、ISO27001 等合规要求，审计时无需额外补材料，所有研发活动天然留痕、可验证。
官方详细解决方案：https://www.aliyun.com/product/list/alibabacloudnative
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践，通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式，助力制造业企业高效上云，实现系统稳定、应用敏捷智能。拥抱云原生，让创新无处不在。