Git 日常工作流：我在团队里怎么用 Git

Git 团队工作流实录：三年多没翻过车

Git 命令上百个，日常真的用的就那一小撮。这套流程我在团队里跑了三年多，从单干到几个人一起合代码，每天重复这套。写下来给刚接触、或者还在"每次都要查一下"的人参考。

三个区

工作区(改文件) → git add → 暂存区 → git commit → 仓库(本地)
仓库 → git push → 远程仓库

日常就两个命令摸状态：git status 看改到哪一步，git diff 看具体改了啥（--staged 看暂存区差异）。

提交信息要能读

这是我后来才悟到的，比命令重要。提交信息是写给一个月后的自己、和一起 review 的同事看的，乱写"update"、"改一下"，一个月后自己都看不懂。

现在用这种格式：

feat(project): 支持多合同配置及项目权限管理
fix(dynamic-page-edit): 修复按钮渲染导致 ESLint 失败
docs: 更新代码审核规范
revert: 回滚提交

习惯：

• feat(scope) 的 scope 写模块名，翻日志一眼看出改的是哪块。
• 一个提交只做一件事。我把两个功能混在一个提交里过，想单独回滚其中一个根本没法拆，只能整条 revert 重来。疼一次就老实了。
• 提交前用 git add -p 一行行挑，把调试用的 console.log 和临时配置剔掉，别一股脑 git add .。

分支：一个功能一条线

develop（主干，只合并 MR）
  └─ feature/afei/yyMMdd-功能描述  → push → 提 MR → 合入
  └─ hotfix/afei/yyMMdd-紧急描述   → 线上 bug

分支名带日期和用途，谁开的、哪天、干嘛的，一眼清楚。主干保持干净，互不干扰，合并前还能 review。就算自己写自己的也建议这么干——出问题整条分支能退。

同步主干：rebase 还是 merge

功能分支写一半，主干更新了：

git fetch origin
git rebase origin/develop

merge 留合并提交，历史真实但乱；rebase 捋成直线看着清爽，但只能对自己没推过的分支用。我 rebase 过已 push 的分支，远程历史对不上，最后 force push 才擦干净。现在习惯：本地合并前 rebase 跟上最新 develop，提 MR 合回 develop 用 merge。

改错了怎么回退

需求	命令
撤销工作区改动	git restore 文件
撤销某次提交（保留历史）	git revert <commit>
软回退，改动留在暂存区	git reset --soft <commit>
硬回退，改动全丢（慎用）	git reset --hard <commit>

revert 生成反向提交，已 push 也能用，安全。reset --hard 真丢东西，用前先 git stash。干到一半要切分支修紧急 bug，git stash 藏起来，修完 git stash pop 取回。

冲突：躲不掉，平常心

文件里会标出来：

<<<<<<< HEAD
你的代码
=======
别人的代码
>>>>>>> origin/develop

三步：打开文件，留对的删标记；git add 告诉 Git 处理好了；git commit 完事。冲突时先看上下文再决定留哪边，别闭眼"采用传入"——我干过一次，把别人改好的逻辑覆盖了，又返工。

完整流程

develop → 开 feature/afei/日期-描述
→ 小步提交（一个提交一件事）
→ 每天 fetch + rebase 最新 develop
→ 做完 push → 提 MR → review → 合入 develop
→ 线上 bug：开 hotfix，快速修，快速合

这套能一直用，靠的不是高级命令，是三个朴素的习惯：提交信息写清楚、分支各管各的、每天跟上主干别攒着。做到这几个，Git 就从"一提就慌"变成"随手就用"。

---

原文链接：https://blog.fateguy.com/posts/git-workflow