单人开发 vs 团队协作

自己用 Git：一个 main 分支，写完就 commit，push 完事。

团队协作这样搞不行——每个人都在 main 上改，冲突是迟早的事。这学期课程项目三个人一起写，第一周就踩坑了。

分支策略：Git Flow 简化版

全量 Git Flow 太复杂，小团队用简化版就够了：

  • main：生产分支，只合并不直接改
  • dev：开发分支，日常集成
  • feature/xxx：功能分支，从 dev 拉，改完合并回 dev

工作流示例：

# 1. 从 dev 拉取最新代码
git checkout dev
git pull origin dev

# 2. 创建功能分支
git checkout -b feature/user-login

# 3. 开发、提交
git add .
git commit -m "feat: 实现用户登录接口"

# 4. 合并回 dev
git checkout dev
git merge feature/user-login

# 5. 推送
git push origin dev

# 6. 删除已合并的分支（可选）
git branch -d feature/user-login

合并冲突：遇到了别慌

冲突长这样：

<<<<<<< HEAD
print("Hello from dev")
=======
print("Hello from feature")
>>>>>>> feature/test

======= 上面是当前分支的内容，下面是合并进来的内容。解决步骤：

# 1. 查看哪些文件冲突
git status

# 2. 手动编辑冲突文件，改成想要的样子
# 改成：print("Hello World")

# 3. 标记已解决
git add 冲突文件

# 4. 完成合并
git commit

教训：冲突不可怕，可怕的是不看内容直接全部接受或全部拒绝。逐行确认才是正确做法。

Pull Request 流程

GitHub 上走 PR 而不是直接 push main：

  1. 推送功能分支到远程：git push origin feature/user-login
  2. 在 GitHub 上创建 PR，目标选 dev
  3. 描述改了什么、为什么改、怎么测试
  4. 队友 Review，提意见
  5. 修改后重新 push，PR 自动更新
  6. 至少一人 Approve 后合并

常用配置

# 设置别名（节省打字）
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"

# 之后可以用 git lg 代替长命令

总结

团队协作 Git 三板斧：分支隔离开发、冲突冷静处理、PR 代码审查。记住一条铁律——永远不要在 main 上直接改代码。