Git 工作流最佳实践：团队协作中的分支策略
Git Workflow Best Practices Branch Strategies for Team Collaboration
| iDev Team | 2026-08-11T07:11:00
从 Git Flow 到 Trunk-Based，不同团队规模适合不同的分支策略。本文结合 iDev 实践经验，给出小团队 Git 工作流的最佳方案。
From Git Flow to Trunk-Based development, different team sizes need different branch strategies. This article shares iDev's practical experience on Git workflows for small teams.
为什么分支策略很重要？ 在 iDev 早期，我们也踩过 Git 管理的坑：代码冲突频繁、发布流程混乱、hotfix 不知道该从哪个分支拉。一套好的分支策略可以让团队协作效率提升 50%。 主流分支策略对比 Git Flow 适合大型项目和版本发布制的产品。有 main、develop、feature、release、hotfix 五种分支类型。优点是流程清晰，缺点是分支管理复杂，对小团队来说太重了。 GitHub Flow 只有 main 和 feature 两种分支，所有 feature 分支通过 PR 合并到 main。简单直观，适合持续部署的 Web 项目。 Trunk-Based Development 所有开发者直接在 main 分支上工作，通过 Feature Flag 控制功能发布。适合 CI/CD 成熟度高的团队。 iDev 的选择：改良版 GitHub Flow 我们在实践中总结出一套适合 5-10 人小团队的方案： main 分支：始终保持可部署状态，受保护，只能通过 PR 合并 feature/xxx 分支：从 main 拉出，开发完成后提 PR 命名规范：feature/模块-描述，如 feature/news-image-upload PR 规则：必须经过至少一人 Review，CI 通过后才能合并 Squash Merge：合并时使用 Squash，保持 main 的提交历史整洁 实用 Tips 每天开工前先 git pull --rebase，减少冲突 Commit message 遵循 Conventional Commits 规范 使用 git stash 暂存未完成的工作，而不是半成品 commit 定期清理已合并的远程分支
Why Branch Strategy Matters In iDev's early days, we experienced common Git pitfalls: frequent code conflicts, chaotic release processes, and confusion about which branch to create hotfixes from. A good branch strategy can improve team collaboration efficiency by 50%. Comparing Branch Strategies Git Flow Suited for large projects with versioned releases. Uses five branch types: main, develop, feature, release, and hotfix. Clear process but complex management — too heavy for small teams. GitHub Flow Only main and feature branches. All feature branches merge to main via PRs. Simple and intuitive, ideal for continuously deployed web projects. Trunk-Based Development All developers work directly on the main branch, controlling releases with Feature Flags. Best for teams with mature CI/CD pipelines. iDev's Choice: Enhanced GitHub Flow Through practice, we've developed a workflow suited for small teams of 5-10: main branch: Always deployable, protected, merges only via PRs feature/xxx branches: Created from main, PR submitted when complete Naming convention: feature/module-description, e.g., feature/news-image-upload PR rules: Requires at least one review approval and passing CI before merge Squash Merge: Use squash merging to keep main's commit history clean Practical Tips Start each day with git pull --rebase to reduce conflicts Follow Conventional Commits for commit messages Use git stash for unfinished work instead of half-baked commits Regularly clean up merged remote branches