要查看已被删除的远程分支，可通过以下方法操作：
方法 1：通过git fetch结合过滤命令查看
执行 git fetch --prune（或简写 git fetch -p），该命令会清理本地对远程已删除分支的引用，然后执行 git branch -a，此时列出的远程分支（以remotes/origin/开头）就是当前远程仓库实际存在的分支，之前已删除的远程分支引用会被移除，通过前后对比可识别已删除的远程分支。
方法 2：查看 Git 操作历史（针对本地曾跟踪过的已删除远程分支）
执行 git reflog show origin/feature-xxx（将feature-xxx替换为疑似已删除的远程分支名），可查看该远程分支的引用变更历史，若历史中存在删除操作记录，可确认该远程分支已被删除。
git branch -d 是 Git 中本地分支的命令，语法为：
功能说明：
- 该命令会删除指定的本地分支，但有一个前提：被删除的分支必须已经完全合并到当前分支（或其他已保存的分支），否则 Git 会提示错误，防止误删未合并的代码。
强制删除未合并的分支：
如果确定要删除未合并的本地分支（可能丢失未合并的修改），可以使用强制删除命令：git branch -D <分支名>（注意是大写的 -D，本质是 -d + --force 的组合）
地分支 的命令，语法为：git branch -d <分支名>
一、企业级开发流程
企业级开发流程通常遵循需求→设计→开发→测试→发布→运维的全生命周期管理，结合 DevOps 和 CI/CD 实践实现高效迭代：
- 需求与设计阶段
- 产品经理梳理业务需求，输出 PRD（产品需求文档）；
- 技术团队进行架构设计、方案评审，明确技术选型和系统边界。
- 开发与集成阶段
- 开发者基于需求创建功能分支（如
feature/user-login），在本地完成编码和单元测试； - 通过 Git 提交代码，触发 CI（持续集成） pipeline，自动执行代码检查、编译、集成测试；
- 代码审查（Code Review）通过后，合并到开发主干（如
develop分支）。
- 开发者基于需求创建功能分支（如
- 测试与预发布阶段
- 测试团队在测试环境对集成后的功能进行系统测试、性能测试、安全测试；
- 若需灰度验证，会在预发布环境小范围部署，模拟生产流量；
- 测试通过后，创建预发布分支（如
release/v1.2.0），准备上线。
- 发布与运维阶段
- 预发布分支通过最终验证后，合并到主分支（
master）并打版本标签（如v1.2.0）； - 通过 CD（持续部署）自动推送到生产环境，运维团队持续监控系统稳定性，收集用户反馈。
- 预发布分支通过最终验证后，合并到主分支（
二、系统开发环境
企业级系统通常划分多套隔离环境，保障开发效率与生产稳定性：
| 环境类型 | 用途说明 | 技术特点 |
|---|---|---|
| 开发环境 | 开发者日常编码、调试，集成功能分支代码 | 开启详细日志、错误提示；配置灵活，支持频繁变更；通常关联develop分支 |
| 测试环境 | 功能测试、集成测试、回归测试，模拟生产场景验证功能 | 与生产环境配置一致（如数据库、中间件）；数据可模拟；关联release或develop分支 |
| 预发布环境 | 上线前最终验收，验证版本稳定性和兼容性 | 与生产环境完全一致（代码、数据、配置）；独立部署，不接入线上流量；关联release分支 |
| 生产环境 | 正式对外提供服务的线上环境 | 安全性、稳定性优先；关闭调试日志，开启错误监控；仅关联master分支，且严格c |
三、Git 分支设计模型
企业常用的分支模型需兼顾协作效率与版本稳定性，以下是三种主流实践：
1. Git Flow（传统稳定型）
适合版本发布周期明确的项目（如传统企业软件），分支职责清晰：
master：生产环境分支，只读且稳定，仅合并release或hotfix分支，每次上线打版本标签（如v1.0.0）。develop：开发主干，集成所有功能分支，是feature分支的父分支。feature/*：功能分支，基于develop创建，命名如feature/payment-module，开发完成后合并回develop。release/*：预发布分支，基于develop创建（如release/v1.0.0-202510），用于测试和上线前准备，合并到master和develop后删除。hotfix/*：紧急修复分支，基于master创建（如hotfix/login-bug），修复线上 Bug 后合并到master和develop，然后删除。
2. GitHub Flow（敏捷迭代型）
适合持续交付的互联网项目（如 SaaS 产品），流程轻量：
- 只有一个长期分支
main（或master），始终保持可部署状态。 - 所有功能开发从
main创建临时分支（如feature/new-feature），开发完成后通过 Pull Request（PR）合并回main，合并后立即部署。 - 若需紧急修复，直接从
main创建hotfix分支，修复后合并并部署。
3. GitLab Flow（灵活适配型）
结合 Git Flow 和 GitHub Flow 的优点，支持多环境隔离：
main：主分支，对应生产环境，始终可部署。feature/*/bugfix/*/hotfix/*：基于main创建，分别用于功能开发、缺陷修复、紧急修复。- 可选
release/*分支：用于预发布测试，若项目需版本化发布则创建，否则直接从main部署。
master 分支
- master 为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，一般由合并 release 分支得到。
- 主分支作为稳定的唯一代码库，任何情况下不允许直接在 master 分支上修改代码。
- 产品的功能全部实现后，最终在 master 分支对外发布，另外所有在 master 分支的推送应该打标签（tag）做记录，方便追溯。
- master 分支不可删除。
release 分支
- release 为预发布分支，基于本次上线所有的 feature 分支合并到 develop 分支之后，基于 develop 分支创建。可以部署到测试或预发布集群。
- 命名以 release/ 开头，建议的命名规则: release/version_publishtime。
- release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以 release 分支代码为基准进行提测。
- 如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
- release 分支属于临时分支，产品上线后可选删除。
develop 分支
feature 分支
- develop 为开发分支，基于 master 分支创建的只读且唯一分支，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。
- 可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发（非常不建议）。
- feature 分支通常为新功能或新特性开发分支，以 develop 分支为基础创建 feature 分支。
- 命名以 feature/ 开头，建议的命名规则: feature/user_createtime_feature。
- 新特性或新功能开发完成后，开发人员需合到 develop 分支。
- 一旦该需求发布上线，便将其删除。
实践建议
- 中小型团队或高频迭代项目，优先选择GitHub Flow，减少分支管理成本；
- 传统行业或版本发布周期长的项目，采用Git Flow保障版本稳定性；
- 需区分多环境（开发 / 测试 / 生产）的企业，可基于GitLab Flow定制分支策略，结合 CI/CD 工具（如 GitLab CI、Jenkins）实现自动化部署。