前言
之前写代码的时候，一直是自己一个人在本地仓库里瞎搞，直到后来开始跟别人协作，才发现 Git 的工作流真的很重要。如果你也是一个人写项目，可能觉得 git add → git commit → git push 就完事了，但一旦涉及到多人协作，就会出现各种冲突和混乱。
这篇文章就来聊聊几种常见的 Git 工作流，以及我在实际项目中是怎么用的。
Centralized Workflow
最简单的工作流，就是所有人直接在 main 分支上工作。这种适合小团队或者个人项目，没什么花里胡哨的东西：
特点：只有一个主分支，所有人直接 push 到 main
命令也很简单：
git pull origin main— 先拉最新代码git add .— 暂存修改git commit -m 你的提交信息— 提交git push origin main— 推送
但是问题来了，如果两个人同时改了同一个文件的同一个地方，push 的时候就会冲突。这时候需要先 git pull，手动解决冲突，然后再 push。
Feature Branch Workflow
这个是我在实际项目中用得最多的。核心思想就是：每开发一个新功能，就新建一个分支，开发完了再合并到 main。
比如你要开发一个用户登录功能：
- 从 main 创建新分支：
git checkout -b feature/user-login - 在这个分支上开发，随便 commit
- 开发完了，push 到远程：
git push origin feature/user-login - 创建 Pull Request（或者 Merge Request）
- Code Review 通过后，合并到 main
这种工作流的好处是 main 分支始终保持稳定，不会出现有人提交了半成品代码导致整个项目跑不起来的情况。
Gitflow Workflow
Gitflow 是一种更复杂的工作流，适合大型项目和正式的发布流程。它定义了好几种分支类型：
- main：永远是稳定的、可发布的版本
- develop：开发分支，集成各个 feature
- feature/*：功能分支，从 develop 创建
- release/*：发布准备分支
- hotfix/*：紧急修复分支
说实话，我在学校项目里没怎么用过这个，因为太重了。但是据说在一些大公司里，这种工作流很常见，特别是需要严格版本管理的项目。
Forking Workflow
如果你参与过开源项目，应该对这个不陌生。基本流程是：
- Fork 别人的仓库到自己的账号下
- Clone 到本地开发
- Push 到自己的远程仓库
- 向原仓库提 Pull Request
这种工作流的好处是，你不需要有原仓库的写权限就能贡献代码。GitHub 上大部分开源项目都是用这种模式。
实际项目中的选择
说了这么多，实际项目中该怎么选呢？我的经验是：
- 个人项目：Centralized Workflow 就够了，简单直接
- 2-5 人小团队：Feature Branch Workflow，够用且灵活
- 大团队/正式项目：Gitflow，虽然复杂但规范
- 开源贡献：Forking Workflow，这是标准流程
我个人最常用的是 Feature Branch Workflow，因为大部分项目都是小团队协作，这种工作流既不会太复杂，又能保证代码质量。而且配合 GitHub 的 Pull Request 功能，Code Review 也很方便。
一些实用的 Git 命令
最后分享几个我在日常开发中常用的 Git 命令：
git stash：临时保存当前修改，比如你正在开发一个功能，突然需要切换分支修 bug，就可以用 stash 先把当前修改存起来。
git log --oneline --graph：用图形化的方式查看分支历史，特别直观。
git rebase -i HEAD~3：交互式变基，可以合并、修改、删除最近的几次提交。这个在整理 commit 历史的时候很有用。
好了，以上就是我对 Git 工作流的一些理解和实践。希望能对你有帮助。