预计阅读时间：4 分钟
假设你现在要开发一个功能：
手机号登录。
标准流程不是直接开写，而是先同步主分支。
git checkout main
git pull origin main
这一步很重要。
如果你的 main 已经过时，后面合并时更容易出现冲突。先拉最新代码，等于从一个干净、最新的起点出发。
接着，创建功能分支：
git checkout -b feature/login
这行命令做了两件事：
- 创建
feature/login - 切换到这个分支
现在你就可以放心开发登录功能了，比如：
- 登录接口
- Token 验证
- 页面 UI
- 表单校验
开发过程中，不建议把所有修改攒到最后一次性提交。更好的做法是按阶段提交：
git add .
git commit -m "feat(login): add sms login api"
继续开发页面后，再提交一次：
git commit -m "feat(login): add login page ui"
这样做的好处是，Git 历史会更清楚。别人能看懂你每一步在做什么，出了问题也更容易定位。
提交信息不要再写：
git commit -m "修改"
推荐这种格式：
feat(login): add sms verification
fix(login): resolve token refresh issue
refactor(login): simplify auth logic
含义很直观：
feat：新增功能fix：修复问题refactor：重构代码
本地开发完成后，把分支推送到远程：
git push origin feature/login
这时候，远程仓库里也会出现你的功能分支。
接下来就是发起 PR。
PR 不是简单的“提交代码”，它真正的意思是：
我开发完了，请帮我审查并合并。
团队成员会在 PR 里做几件事：
- 看代码有没有明显问题
- 检查实现是否符合需求
- 跑自动化测试
- 提出修改建议
- 确认后合并到 main
很多 Bug，都是在 PR 阶段被提前发现的。
所以 PR 的价值不是流程感，而是质量控制。
命令速查：
git checkout main # 切换主分支
git pull origin main # 拉取最新代码
git checkout -b feature/login # 创建并切换功能分支
git add . # 添加修改
git commit -m "feat(login): add api" # 提交代码
git push origin feature/login # 推送远程分支
3 个关键点：
- 开发前先同步最新
main。 - 提交信息要清楚，不要只写“修改”。
- PR 的本质是代码审查，不只是提交代码。
#Git #团队协作
本文由 楸木 原创，转载请注明出处。