掌握各种Git工作流程，提升团队协作效率和代码质量
Git工作流程是团队在使用Git进行版本控制时遵循的一系列约定和规则。选择合适的工作流程可以提高团队协作效率，减少冲突，并确保代码质量。
类似于SVN的简单工作流，所有开发者直接向中央仓库推送更改。
每个新功能都在独立分支上开发，完成后合并到主分支。
严格定义的分支模型，包含功能、发布、热修复等分支类型。
每个开发者fork主仓库，在个人副本上工作，通过Pull Request贡献代码。
集中式工作流是Git最简单的协作方式，特别适合从SVN等集中式版本控制系统迁移过来的团队。
所有开发者直接克隆中央仓库，进行更改后直接推送到中央仓库。
每个开发者克隆中央仓库到本地：
在本地进行更改并提交到本地仓库：
在推送前，先获取中央仓库的最新更改：
如果有冲突，需要先解决冲突。
将本地更改推送到中央仓库：
注意： 在团队协作中，频繁地进行git pull可以减少冲突的发生。
功能分支工作流的核心思想是每个功能都应该在独立的分支上开发，完成后通过合并请求(Pull Request)集成到主分支。
每个功能在独立分支上开发，完成后合并到主分支。
基于主分支创建新的功能分支：
在功能分支上进行开发并定期提交：
功能完成后，在GitHub/GitLab等平台上创建合并请求(Pull Request)。
团队成员在合并请求中进行代码审查和讨论。
通过代码审查后，将功能分支合并到主分支：
合并完成后，删除本地和远程的功能分支：
Gitflow工作流由Vincent Driessen提出，定义了严格的分支模型，适合有发布周期的大型项目。
Gitflow包含五种分支类型：主分支(main)、开发分支(develop)、功能分支(feature)、发布分支(release)和热修复分支(hotfix)。
存放稳定、可发布的代码版本，每个提交都应该对应一个版本标签。
集成功能分支的代码，是功能开发的主要分支。
从develop分支创建，用于开发新功能，完成后合并回develop分支。
从develop分支创建，用于准备发布，只进行bug修复和文档更新，完成后合并到main和develop分支。
从main分支创建，用于紧急修复生产环境中的bug，完成后合并到main和develop分支。
提示： 可以使用git flow扩展工具来简化Gitflow工作流的操作。
Forking工作流是开源项目最常用的协作模式，每个贡献者拥有项目的独立副本，通过Pull Request向主项目贡献代码。
每个开发者fork官方仓库，在个人副本上工作，通过Pull Request向官方仓库贡献代码。
在GitHub/GitLab上fork官方仓库，创建个人副本。
克隆fork后的仓库到本地：
添加官方仓库作为上游远程仓库：
创建功能分支进行开发：
将功能分支推送到你的fork仓库：
在GitHub/GitLab上创建Pull Request，请求将你的更改合并到官方仓库。
定期从官方仓库获取最新更改，保持你的fork同步：
| 工作流程 | 复杂度 | 团队规模 | 发布频率 | 主要优势 |
|---|---|---|---|---|
| 集中式工作流 | 低 | 小型团队(1-5人) | 不频繁 | 简单易学，迁移成本低 |
| 功能分支工作流 | 中 | 中小型团队(3-10人) | 中等 | 功能隔离，便于代码审查 |
| Gitflow工作流 | 高 | 中大型团队(5-20人) | 有计划的发布 | 严格的发布管理，支持并行开发 |
| Forking工作流 | 中高 | 大型分布式团队 | 不固定 | 安全的贡献模式，维护者完全控制 |
编写清晰、一致的提交消息，使用约定式提交(Conventional Commits)格式：
每个提交应该只包含一个逻辑更改，避免将多个不相关的更改放在同一个提交中。
使用git add -p进行交互式暂存，选择要提交的更改。
定期从上游仓库获取最新更改，减少合并冲突：
使用rebase而不是merge可以保持历史记录整洁。
使用一致的分支命名约定：
feature/简短描述fix/问题描述release/版本号hotfix/问题描述在合并前整理提交历史：
设置分支保护规则，要求：