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

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

三个区

这模型记牢了，很多命令就顺了：

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

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

提交信息要能读

这是我后来才悟到的，比命令本身重要。提交信息不是写给 Git 看的，是写给一个月后的自己、和一起 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 → 合入 develop
  └─ hotfix/afei/yyMMdd-紧急描述       ← 线上 bug

分支名我会带上日期和用途，比如 feature/afei/260803-perf-optimization，谁开的、哪天开的、干嘛的，一眼清楚。

git switch -c feature/afei/260803-perf-optimization

主干保持干净，每个人在各自分支上折腾，互不干扰，合并前还能过一遍 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 就从”一提就慌”变成”随手就用”。