接手一个前端项目，第一件事不是跑npm install，而是先把 Git 仓库的状态摸清楚。这不是我矫情，而是这几年看太多新同事一上来就git add .、git commit -m "update"，把提交历史搞得一团糟，等要回溯问题的时候，整个仓库跟迷宫一样，谁碰谁头疼。前端开发里的 Git 应用，表面上是命令行的机械操作，实质是工程化思维的第一课。分支怎么拉、提交怎么写、代码怎么合、线上出问题怎么快速回滚，这一整套流程直接决定你是一个“会写代码的人”，还是一个“能交付项目的人”。

这篇内容我从自己实际踩过的坑出发，把前端场景下 Git 的使用从基础配置、分支协作、高频操作，到疑难杂症的排查，按一套相对完整的思路拆开讲。不堆概念，不做文档搬运工，全程以实操为准。不管你是刚入行的小白，还是被 Git 折磨过的“资深受害者”，这套经验应该都能帮你在团队协作里少走不少弯路。

1. Git环境配置里那些容易忽略的细节点

1.1 全局配置与仓库级配置要分清

很多人装完 Git 就稀里糊涂开始用，等到提交的时候发现用户名是“user”，邮箱是一串乱码，推上去之后代码评审系统根本不认。这里第一个建议就是：全局配置和仓库级配置，从一开始就要想清楚分别该填什么。

全局配置负责的是你这台机器的“身份”，通常用个人常用的姓名和邮箱。仓库级配置则服务于特定项目，很多公司要求提交邮箱必须是企业邮箱，这时候就不要在全局改，而是进入项目目录单独设置：

# 全局配置（你的个人身份） git config --global user.name "你的昵称" git config --global user.email "你的常用邮箱" # 仓库级配置（公司项目强制要求时） git config --local user.name "你的中文名" git config --local user.email "姓名@公司域名.com"

这里有个细节，--local配置保存在项目目录下的.git/config文件里，它永远不会被推到远程仓库，也不会影响你其他项目。我曾经见过有人为了满足某个项目的提交要求，直接改了全局配置，结果后面所有个人项目的提交记录都带着公司的邮箱，搞得很尴尬。

另外两个配置建议设好。一个是默认编辑器，git commit打开编辑器的体验直接影响你写提交信息的效率：

git config --global core.editor "code --wait"

另一个是换行符处理，特别是在前端项目里，不同操作系统的同事协作时，这个配置能避免大量无意义的 diff：

# Windows 用户 git config --global core.autocrlf true # macOS / Linux 用户 git config --global core.autocrlf input

很多前端项目里出现整个文件变红、变绿，往往不是有人动了代码，而是换行符在捣鬼。这两行配置能帮你省掉一大半这种“幽灵 diff”的困扰。

1.2 换行符与编码问题的坑

说句实在话，前端项目里因为换行符闹出的“全文件改动”事件，几乎每个团队都经历过。比如一个文件在 Windows 上被编辑器保存成了 CRLF，提交后，另一个用 macOS 的同事一打开就被自动转成 LF，然后他改了一行代码保存，Git 发现整个文件都被修改了。你以为是不怀好意的同事改了你的代码，其实只是换行符在作怪。

除了配置core.autocrlf，还需要在项目根目录放一个.gitattributes文件，把规则固定下来：

# .gitattributes 常见配置 * text=auto *.js text eol=lf *.json text eol=lf *.md text eol=lf

这个文件的作用是告诉 Git：这个仓库里的这些文件，永远以 LF 作为换行符保存。它会被提交到远程仓库，所有协作者都会遵循这一规则。其实把它理解为项目的“换行符宪法”就行，有了这个东西，跨平台协作的换行符问题基本就绝迹了。

编码问题同样值得提一句。前端项目里的GBK编码文件，在git diff里显示中文乱码的坑，很多老手都遇到过。最快的解决方案是把所有源文件统一为 UTF-8 编码，同时设置：

git config --global core.quotepath false

这个配置让 Git 在显示中文文件名时不再转义成\345\274\200...这种八进制序列，直接显示中文。遇到乱码问题，先检查文件编码，再检查这个配置，基本能解决九成以上。

2. 从需求到合入：前端分支协作的日常节奏

2.1 分支命名与保护分支策略

在团队协作里，分支命名的重要性被严重低估。很多人随手git checkout -b fix，或者git checkout -b dev，看着是挺利索，但一旦分支多起来，光看名字根本不知道这个分支对应什么需求、是谁在维护、要不要合到主干。我比较推荐一套简单实用的命名约定：

feature/需求标识-简短描述 fix/问题描述 release/版本号 hotfix/问题编号

比如feature/LOGIN-1024-remember-me、fix/input-cursor-position，一眼就能看出它是什么任务。配合远程分支的清理习惯，定期删除已经合并的分支，远程仓库就不会变成“分支坟场”。

主干分支一定要设置保护规则。简单说，就是不允许任何人直接推送到主干分支，所有变更必须通过合并请求。在代码托管平台上都叫 “Protected Branch” 或者“分支保护规则”，开启后大家只能提交合并请求，由指定的人审核后合入。

我见过不少前端团队，主干分支形同虚设，谁都能直接推，最后代码冲突、上线出了问题都不知道是哪次提交引入的。保护主干分支不是为了限制自由，而是给“线上稳定”兜底。

2.2 提交信息的规范写法与原子化提交原则

关于提交信息，网上吵得最凶的就是“要不要写中文”。我的观点很简单：只要团队内部能统一，中英文都行。关键是信息本身的表达效率要高。

我自己的模板是：

<type>(<scope>): <subject> <body>

其中的类型，最常用的是feat（新功能）、fix（修复）、refactor（重构）、perf（性能优化）、chore（杂项）、style（格式）、docs（文档）。比如：

fix(Form): 修复必填项校验在异步数据加载后不生效的问题 异步表单数据到达后，表单组件未触发重新校验。 在数据更新后手动调用 validateFields，确保用户感知到错误提示及时更新。

这种“一句话主题 + 若干行背景说明”的写法，比“update”好一万倍。等到出问题追溯的时候，你看着描述至少能判断问题的引入范围。

原子化提交的意思是：一次提交只做一件事。改动三个文件分别是修复一个 bug、调整一个样式、优化一段逻辑，那就拆成三个提交，不要塞在一个 commit 里。好处有两个：一是代码评审的效率高，逻辑清晰；二是哪天要git revert某一个提交，不会把其他不相关的改动也一起回滚。

2.3 冲突解决的正确姿势

冲突是 Git 使用中最“劝退”新人，也最能拉开老手差距的场景。发生冲突的本质是两个分支修改了同一个文件的同一段区域，Git 没法替你判断该保留哪个版本。

我的冲突处理习惯分四步走：

第一步，先看冲突文件列表，评估冲突范围：

git status

第二步，打开冲突文件，搜索冲突标记<<<<<<<、=======、>>>>>>>，定位冲突代码。不要盲改，务必要看上下文。

第三步，判断该保留哪边的代码。这里有个实操经验：如果冲突发生在自己和同事之间，直接找同事沟通，确认代码逻辑，不要凭感觉删。前端组件之间往往有依赖关系，表面看着冲突的是几行代码，背后可能是一整块业务逻辑的取舍。

第四步，手动解决后，一定要本地跑一遍相关功能再提交。我吃过一个大亏：某个组件内部状态被另一个分支改了，我合并时把冲突的代码块硬拼在一起，编译是过了，但用户连续点击按钮时状态错乱。后来在浏览器里调试了一下午才发现是合并时少保留了一个分支的初始化逻辑。这个问题很典型，前端项目的冲突，编译通过和功能正常完全是两回事。

合并冲突解决后，顺便提一下git rerere这个内置功能：

git config --global rerere.enabled true

开启后，Git 会记录你解决冲突的方式，下次同样的冲突出现时自动应用。听起来很智能，但我的建议是：不建议太依赖它。因为冲突场景往往伴随着复杂上下文，自动套用上一次的解法，可能结果并不符合当下实际，手工核对仍然有必要。

3. 前端高频场景的Git操作拆解

3.1 暂存区不只是“中转站”

很多前端开发者的日常工作状态是：改着需求 A 的代码，突然线上出了个紧急 bug。这时候本地工作区一半是需求 A 的改动，一半是 bug 修复的代码，全都混在一起。

git stash就是专门处理这种场景的。但要注意，stash的用法并不只是git stash save然后git stash pop这么简单。工作中我常用的组合是：

# 暂存所有未提交的改动 git stash # 只暂存某个文件的改动 git stash push -m "需求A进行中" src/components/Form.js # 查看暂存列表 git stash list # 恢复最近一次暂存 git stash pop # 恢复并删除最近的暂存 git stash apply

有一招特别好用，就是如果在修复紧急 bug 之前，需要保持需求 A 的改动，但不希望它出现在当前工作区，此时执行git stash push -m "LOGIN-1024 in progress"，等你修完 bug、提交并推送到分支之后，再git stash pop恢复。这个流程非常顺。

不过stash有局限——它默认只暂存已跟踪的文件的改动，新建的未跟踪文件不会被带进去。如果你想连新文件也一起暂存，需要加上-u参数：

git stash -u

如果你有一堆新文件，还不想被暂存，忽略它就行。留意的是，执行git stash pop的时候，如果当前工作区和 stash 记录的改动冲突了，Git 会提示你，如果后续改动已经把对应代码改得面目全非，这个pop可能失败。此时不要慌，用git stash show -p stash@{0}查看细节，手动处理。

3.2 cherry-pick：精准摘取提交

前端项目里有个高频场景：需求分支开发到一半，线上突发一个 bug 需要立刻修复。修复代码如果在另一个分支上已经写好并测试通过了，让主分支合入整个分支会惹来一堆不相关改动。这时候就需要git cherry-pick，精准地把那一个提交摘过来。

# 把 feature 分支上某个 commit 摘到当前分支 git cherry-pick abc1234 # 摘多个提交 git cherry-pick abc1234 def5678 # 只摘改动不生成提交（进入暂存区），自己重新 commit git cherry-pick -n abc1234

这里有个实际场景。发布分支已经切出来了，测试过程中发现一个 bug，修复代码提交在 feature 分支上。此时用cherry-pick把这个修复带进发布分支，比在发布分支上手动改代码更安全、更容易追溯。等发布分支上线后，主分支合并时一般不会冲突，因为两个分支都基于同一个历史节点修改，Git 能自动帮你合并。

cherry-pick在遇到冲突时，实行的处理逻辑和merge差不多，需要手动解决，然后：

git cherry-pick --continue

如果中途发现摘错了，可以：

git cherry-pick --abort

一个容易被忽视的点是：cherry-pick会创建一个全新的提交对象，原始提交和摘出来的提交虽然“内容一致”，但时间、哈希都不相同。这会导致一个问题：你原本cherry-pick abc1234，之后又想把原分支合并进来，会觉得 Git 有点“笨”，两个提交内容一样却还产生了重复操作。这就是为什么能用 merge 解决时优先用 merge，而不要频繁用 cherry-pick 来替代 merge。

3.3 rebase 的使用边界

说到rebase，前端圈里讨论度最高的一句话就是：不要对公共分支执行 rebase。这句话是对的，但又常常被理解得太绝对。

rebase的核心价值在于让提交历史变得线性，方便阅读。比如你在 feature 分支上开发，主干分支已经前进了一些，我习惯先：

git fetch origin git rebase origin/main

把本地 feature 分支的基底移到最新的主干上，让改动看起来像是直接从最新主干长出来的，而不是一大堆分支合并的交点节点。这样后续提合并请求，reviewer 看到的改动就是纯粹的 feature 内容。

但要注意时机。如果这个 feature 分支其他人也在用，或者已经推到了远程，就不要随便 rebase 了。一旦 rebase，原来的提交被新提交替代，两个人基于不同版本的提交进行协作，冲突和混乱很快就会出现。如果分支已经推送到远程并且是共享状态，请改用git merge origin/main，保留合并历史的双向流动。

在团队协作里，我个人的习惯是：本地未推送到远程的分支，可以放心 rebase；已经推送且多人共享的分支，一律 merge。

3.4 revert 与 reset 的选择

线上出问题了，要回滚代码。前端同学第一反应往往是git reset --hard，但这是一个非常危险的操作。reset会移动分支指针，并且如果--hard的话，工作区都会被强制重置，未提交的改动将直接丢失。在已经推送的公共分支上执行reset，然后又强制推送，团队里其他人的本地分支就和你“分道扬镳”了。

推荐的做法是git revert：

git revert abc1234

它会生成一个新的提交，把指定提交的改动“反向应用”。也就是说，历史记录保持完整，新的提交直接把问题代码“撤销”了。这个操作可以在公共分支上安全使用，因为新提交会继续前进，不会改变已经发布的历史。

为什么很多前端项目不敢直接用revert，我分析下来的原因，主要是变更范围比较大的时候，比如一次提交里塞了几十个文件的改动，revert之后又跟当下代码产生冲突。解决思路有一个：不要直接 revert 合并分支的那个 merge commit，处理起来会比较复杂，建议 revert 该合并引入的具体业务代码提交，或者考虑用git revert -m 1 <merge-commit>来处理。真正的答案要根据仓库结构和团队规范来定，这里想强调两点：

• 公共分支上，不要用 reset 回滚已推送的提交
• revert 遇到冲突是正常的，解决完冲突再继续

3.5 看历史：不只是 git log

看提交历史时，git log --oneline是最基础的用法。实际工作中，我更常用这几条：

# 查看某个文件的完整修改历史 git log --follow -p src/components/Button.js # 查看某个提交的变更内容 git show abc1234 # 查看当前分支和主干分支的差异提交 git log --oneline main..feature/LOGIN-1024 # 看某个作者最近一周的提交 git log --author="你的名字" --since="1 week ago" --oneline

前端项目排查样式问题或构建问题的时候，git log --follow -p极其有用。你可以清楚看到哪个提交改了这个文件，具体改了哪一行，从而定位它和其他模块的耦合关系。

这里有一个我的心得：养成每次处理完问题时，回头用git log看一下提交历史，想想自己刚才的操作在历史上留下了什么印记。这个习惯比背一百个命令都重要，它能帮你建立对仓库演变的敏感度。

4. 前端项目特有的Git实战战术

4.1 提测、发布、热修复的标准流程

前端项目的发布节奏通常比后端快，一天好几次发布都不稀奇。在这样的节奏下，需要一整套适合前端业务的 Git 流程模板。

以我常用的分支模型为例：

• main：主干分支，保护分支，只接收合并请求
• develop：开发分支，日常开发从它拉取feature
• release/版本号：提测分支，从 develop 切出，只做 bug 修复
• hotfix/问题编号：线上紧急修复分支，从 main 切出

提测流程一般是：从develop切出release/1.2.0，测试在 release 分支上进行。测试期间产生的 bug 修复直接提交到 release 分支，不要污染 develop。测试通过后，把 release 分支合并回main和develop。

线上热修复流程：从main切出hotfix/ORDER-8080，修复验证后合并回main和develop。这样可以保证线上和开发线都包含这个修复，而不是“修了线上忘了开发线”。

4.2 发布分支上的提交管理

发布分支上最忌讳的事情就是“顺手改”“顺手提交”。一旦随手提交了一个需求 A 的功能代码，而本次提测只包含需求 B，那么 QA 在测试 B 的时候会连带测到 A 的功能，流程上不公平，Bug 归属也不清晰。

具体实操上我会在 release 分支上遵守两个规则：

规则一：所有提交都关联到问题单或需求单。提交信息必须带单号，比如fix(ORDER-8080): 售后列表时间格式化错误，这样不管是测试同学还是运维同学，都可以通过单号快速定位到代码改动的原因。

规则二：release 分支上只做修复，不做功能开发。功能开发一律回到 develop 分支从 feature 分支合入，否则 release 分支会失控，测试环境验证的范围也会失控。

4.3 上古分支清理与仓库瘦身

前端项目跑了一两年之后，仓库会变得越来越大，clone 一次动辄几个 G，git status都开始卡顿。这时候就得考虑“瘦身”。

先检查一下仓库体积：

git count-objects -vH

如果发现体积异常，多半是历史里有大文件，或者二进制文件的多个版本都被长期保留。可以利用git filter-repo这类工具重写历史，把大文件从所有历史提交中移除。这个工具操作威力很大，执行前一定要备份整个仓库。重写历史意味着所有提交哈希都会改变，项目里所有人的本地仓库都必须重新同步。建议极谨慎操作，最好在专门的维护窗口中执行。

日常不起眼的习惯其实更能防止仓库膨胀：不要把 node_modules、dist 目录等构建产物提交进仓库（下一节详谈），不要往仓库里提交日志文件、数据库备份、压缩包。构建产物有 CI 流程去生成，日志文件和备份走对象存储或文档管理，都不该进 Git。

5. .gitignore 与前端工程的边界

5.1 必备的忽略清单

前端项目的.gitignore是我见过被忽略最严重、但实际作用最大的文件之一。一个设计良好的.gitignore可以帮助团队避免提交大量无意义的文件。下面这份清单我修修改改用了很久，可以直接抄作业：

# 依赖 node_modules/ # 构建产物 dist/ build/ output/ # 日志 *.log logs/ npm-debug.log* # IDE 配置 .idea/ .vscode/ *.swp .DS_Store # 环境变量 .env .env.local .env.*.local # 测试覆盖率 coverage/ # 缓存 .cache/ .temp/ .eslintcache

有些同学把.vscode/里的编辑器配置提交进仓库，想让团队统一编辑器风格。这样做的问题是容易演变成个人配置文件的 Tug-of-War，失去统一效果。我的建议是：严格区分“项目级配置”和“个人偏好”。比如.editorconfig和.prettierrc这类与代码格式强相关的配置属于项目级，应该提交；而类似settings.json这种个人习惯设置则应该加入忽略清单。

5.2 边界场景：lock文件该不该提交

前端圈里争论得比较多的一个问题是package-lock.json、yarn.lock或pnpm-lock.yaml该不该提交。我的观点很明确：必须提交。

lock 文件的作用是锁定依赖树中每个包的确切版本。提交它，才能保证团队所有成员npm install出来的依赖是一模一样的，才能保证 CI 的构建环境和你的本地环境是一致的。如果某台机器重新安装依赖后出现了“本地好好的，构建环境挂了”的情况，大概率就是没有正确提交和更新 lock 文件。

要小心的是，如果使用 npm 7 及以上版本，lock 文件结构有较大变化，升级依赖或跨版本使用 npm 会导致 lock 文件大改，合并时容易产生冲突。这种冲突不要手动改，用npm install重新生成即可。

5.3 .gitignore 失效的应急处理

有时明明在.gitignore里写了忽略规则，但git status里文件还在。这种“失效”通常是因为该文件在设置忽略之前就已经被提交到仓库了。.gitignore 只对未跟踪的文件生效，已经提交进仓库的文件，修改 .gitignore 并不会自动把它从仓库中移除。

解决办法是把文件从 Git 的跟踪目录中移除，但保留本地文件：

git rm --cached node_modules -r

执行后修改.gitignore增加对应规则，再提交一次，Git 就不再跟踪它了。这个操作在切换 .gitignore 方案、不小心把dist目录提交进仓库时需要频繁使用。记得提交后同步给团队其他人git pull，否则其他人本地仍然会看到被跟踪的旧文件。

这里还有一个细节，就是git rm --cached之后，如果本地文件发生改动，后续不会再因为该文件产生 diff，因为 Git 已经不对它做跟踪。这个状态对某些团队来说可能需要提前沟通说明，建议在提交信息里注明：“移除 dist 目录出仓库，后续构建产物由 CI 生成”。“后续构建产物由 CI 生成”这句话，在团队协作里能避免很多“咦，dist 怎么不见了”的疑问。

6. 常用命令的进阶玩法与效率技巧

6.1 分支管理的几个高效命令

git branch最基础的用法是查看本地分支，但实际工作中我更常用组合命令：

# 列出所有本地分支以及每个分支最近一次提交 git branch -vv # 列出所有已合并的分支 git branch --merged # 列出所有未合并的分支 git branch --no-merged # 删除本地分支 git branch -d branch-name # 删除远程分支 git push origin --delete branch-name

其中git branch --merged非常实用。每隔一段时间清理已合并分支，就不需要挨个去记忆“这个分支合了没、那个分支还留着吗”。配合git branch -d以及每天下班前的“仓库整理五分钟”，远程分支就能保持干净状态。

6.2 查看当时代码状态的两个“后悔药”

前端开发过程中，经常会遇到“这个文件被我改坏了，我想看看它原来的样子”的情况。用git show就能做到：

# 查看工作区和上次提交的差异 git diff # 查看已暂存和上次提交的差异 git diff --cached # 把某个文件恢复到上次提交时的状态 git checkout -- src/utils/format.js # 查看某个提交里特定文件的内容 git show abc1234:src/utils/format.js

很多前端同学处理“本地代码改坏了”的第一反应是git reset --hard HEAD。这种操作确实爽快，但会连未提交的其他改动一起丢掉。更稳妥的方式是：如果只是单个文件改坏了，用git checkout -- 文件路径只恢复那个文件；如果整个工作区都乱了但还没提交，先用git stash暂存起来，再决定要不要恢复。人的记忆是不可靠的，尤其项目里有多个需求并行时，宁可多备份一层，也不要凭感觉“重来”。

6.3 远程操作绕不开的几个场景

团队协作中，远程分支的变化节奏非常快。每天开工第一件事，我习惯先把远程仓库的最新状态拉下来：

git fetch --all --prune

--prune会同步删除远程已经删掉的分支，避免本地残留一堆已经不存在的远程分支引用。

如果要把远程某个分支拉到本地并切换到它：

git checkout -b feature/LOGIN-1024 origin/feature/LOGIN-1024

如果本地分支和远程分支存在关联关系，直接git pull就好。但也有个效率坑：默认的git pull行为取决于 Git 配置，我把它设置为 rebase，避免每次拉取都生成一个多余的 merge 提交：

git config --global pull.rebase true

这个配置在个人使用上体验不错。但在需要多人协作、分支结构复杂的情况下，每个团队的习惯不同。有些团队明确要求用 merge 方式保证历史轨迹完整，那就得配合团队约定。不要盲目套用。

6.4 距离与差异：查看两个分支的不同

前端项目迭代快，分支之间的差异分析是基本功。我最常用的一组命令：

# 查看两个分支的差异 git diff main..feature/LOGIN-1024 # 查看两个分支的差异文件列表 git diff --stat main..feature/LOGIN-1024 # 查看当前分支和远程分支的差距 git rev-list --left-right --count main...origin/main

比如接到一个任务：“帮忙看一下 feature/LOGIN-1024 和主干的差异”。用git diff --stat一下就能看到大概改了哪些文件，再针对重点文件git diff main..feature/LOGIN-1024 -- src/components/Form.js查看具体改动。这样既高效，又不会“眉毛胡子一把抓”。

7. 常见问题与排查技巧实录

7.1 “这个提交怎么不见了”排查套路

前端协作中最常听到的一句话是：“咦，我昨天提交的代码不见了”。排查思路一般是：

先确认原始提交所在的分支：

git branch --contains abc1234

如果输出为空，说明该提交当前不在任何本地分支上，那它大概率是被 reset 掉了或者 rebase 重写了。这时候不要慌，还有一个兜底机制——Git 的 reflog 会记录 HEAD 的每一次动作：

git reflog

reflog 会显示像是abc1234 HEAD@{0}: commit: fix(Form):...这样的记录，帮助你找回“丢失”的提交。找到后，可以：

git cherry-pick abc1234

把丢失的提交重新摘回来。需要注意，reflog 有保留期限，默认大概 90 天左右。如果提交丢失的时间远超这个范围，能找回的概率就很微茫了。

处理这类问题时，我心里一直有个底线：只回滚自己明确知道后果的代码变更，不做无谓的盲目“恢复”。因为“丢失”的提交可能已经包含在新的提交链里，强行 cherry-pick 反而会造成重复修改。

7.2 merge 提交引发的“重复代码”问题

某个场景我都记不清遇到多少次了：本地的 feature 分支是从旧版本的 develop 拉出来的，自己在上面改了 A 文件；与此同时，另一位同事在 develop 上改了同一区域。你 pull 了 develop 后，合并冲突没看清，A 文件里出现了两份功能几乎相同的代码，但又不是完全一样。

如果只是“代码重复”而不报错，很容易混过去。但这种重复代码常常成为后续线上问题的温床。排查时，我现在的做法是直接用git log --follow -p src/xxx/A.js查看这个文件的完整修改历史，找到冲突合并的那个 commit，看它到底保留和丢弃了什么。如果确实是错误合并引入的重复逻辑，再走一次git revert或者手动删除重复部分，并提交修复。

吃一堑长一智后，我在解决 merge 冲突时有了一个强制习惯：解决完冲突后，必须在本地把相关功能完整跑一遍，尤其是那些跨越多个组件的交互逻辑。因为 Git 的自动合并只关心文本层面，它永远不会懂“两个组件状态同步”这类业务逻辑。

7.3 撤销合并请求需要注意的事项

合并请求合入后，想反悔怎么办？上文提过用git revert来处理。但一旦涉及的是合并请求合入（包含多个提交），直接git revert那个 merge commit 往往很麻烦。

一个实践中的经验是：如果合并请求包含 5 个提交，需要撤销时，不要直接 revert merge commit。更稳妥的做法是：

• 如果需求只上线了一小部分，希望保留一部分功能，就手动挑出需要保留的提交，用git cherry-pick重新提交到一个新分支，然后撤掉整个原本的合并请求
• 如果需求整体下线，可以直接在功能分支上反向操作，再重新合并

个人维护决策时的原则就是：优先保证 main 分支的历史可读性和可回溯性，再考虑便利性。有些东西用起来顺手，但不一定对团队长期健康有益。

7.4 submodule 的使用警示

前端项目里如果有公共组件库，有的团队会用git submodule管理。我的观点是：submodule 能用，但维护成本远比表面看起来高。

用了 submodule 之后，克隆仓库的人需要执行：

git submodule update --init --recursive

子模块的版本要手动更新，子模块的修改要分别提交。多人协作时，最容易出现“你 update 到了新版本，但我没有”，导致大家看到的组件版本不一致，bug 排查时非常痛苦。

如果只是共享少量代码，我更建议把公共代码抽成 npm 包，通过版本号来管理。这样锁定的是明确的版本号，而不是一个“指向某个 commit 的指针”。如果没有特别强制的场景，尽量避免引入 submodule。

写到最后的一点体会

说了这么多，本质上都是围绕“怎么让前端项目的 Git 使用更顺手、更安全、更高效”。我自己的体会是：Git 技巧和命令是可以速成的，但真正拉开差距的是长期维护的习惯。比如每次提交前看一眼 diff、每次拉取前 fetch 一下、每个分支都写清楚描述，这些“小动作”看起来不起眼，但积累到一定规模后，就能让一个项目的协作体验天差地别。

最后分享一个小技巧：把常用的 Git 操作封装成自己的脚本。比如我本地有个glog别名，用一条命令展示最近 15 条提交、作者、相对时间、变更统计，快速浏览项目状态时十分方便：

git config --global alias.glog "log --graph --pretty=format:'%h %ad %an %s' --date=relative --branches --all --max-count=15"

这种自定义别名不需要团队统一，自己开发效率就能明显提升。前端这个领域，工具带来的舒适感是很实在的，而 Git 就是最值得投资的那一个。实践过程中反复遇到问题、反复查阅、反复调整流程，才是我自己走到现在的真实路径。希望这篇经验分享，能让你在一两个关键场景里少踩一些我当年踩过的坑。