长期维护分支主要负责稳定版本和生产环境代码，生命周期通常以年为单位；临时功能分支用于特定任务开发，合并后应立即删除。
先说结论：长期分支保障生产稳定与持续维护，临时分支确保开发隔离与仓库整洁，两者需严格区分管理策略。
- 适合：长期分支用于生产发布（如 master、LTS），临时分支用于功能开发（如 feature、hotfix）。
- 重点看：长期分支有明确的维护周期（如主动/被动维护期），临时分支合并后必须删除。
- 别忽略：临时分支堆积会增加管理成本，需配置自动删除或定期清理。
核心差异解析
长期维护分支（如 master、LTS）的核心目标是稳定性。以 OpenHarmony 为例，Release 分支生命周期为 2 年，LTS 分支可达 3.5 年，期间分为主动维护期和被动维护期，确保企业级应用的持续支持。
临时功能分支（如 feature/*）的核心目标是隔离性。基于 GitFlow 规范，这类分支从开发主干创建，任务完成后合并回主干并删除，避免未成熟代码影响主分支。
常用操作命令
分支管理主要靠规范与配置，以下是清理临时分支的常用命令：
git branch -d <branch-name> # 删除本地已合并分支
git push origin `--delete` <branch-name> # 删除远程分支
git remote prune origin # 清理本地已失效的远程分支引用注意：若分支未合并，使用 -d 会报错，强制删除需谨慎使用 -D。
主流平台保护规则配置
为防止误操作，建议在代码托管平台配置分支保护规则：
GitLab 配置步骤
- 进入项目 Settings > Repository。
- 展开 Protected Branches 区域。
- 选择分支（如 master），设置 Allowed to merge 为 Maintainers，Allowed to push 为 No one。
- 勾选 Prevent pushing 以禁止直接提交。
GitHub 配置步骤
- 进入项目 Settings > Branches。
- 点击 Add branch protection rule。
- Branch name pattern 填写
main或master。 - 勾选 Require a pull request before merging 和 Require status checks to pass before merging。
若在 GitLab 等平台，可在合并请求设置中开启“合并后自动删除分支”选项，减少手动清理成本。
验证与清理
使用 git branch -a 查看分支列表，确认临时分支已消失。检查代码平台设置，确认长期分支开启了保护锁，且合并请求流程正常触发。
定期执行 git remote prune origin 清理本地已删除的远程分支引用，保持本地环境整洁。
常见坑
1. 直接向 master 提交代码：绕过审查会导致生产环境不稳定，应强制通过 MR 合并。
2. 临时分支长期不删除：堆积的分支会造成混淆，建议合并后自动删除。
3. 混淆 Release 与 LTS：LTS 是从 Release 中筛选升级而来，维护周期更长，不可混用。
4. 强制删除风险：使用 git branch -D 前务必确认代码已合并，否则可能导致代码丢失。
原文链接：https://www.zjcp.cc/ask/11316.html