1. 提交前的第一道门槛：环境与仓库准备
1.1 安装Git与三件套配置
很多新手拿到Git的第一步不是写代码，而是被安装和配置劝退。Git的安装本身不复杂，各个系统都有对应方案：Windows推荐直接去官网下载安装包，一路Next就行，记得把"Git Bash Here"和"Git GUI Here"这两个右键菜单加上，后面用起来会顺手很多；macOS可以用Homebrew一条命令brew install git，或者装Xcode Command Line Tools自带的版本；Linux各家发行版走各自的包管理器，Ubuntu/Debian执行sudo apt install git，CentOS/RHEL执行sudo yum install git。
安装只是万里长征第一步，真正让Git能"正常说话"的是安装后的三件套配置。打开终端执行：
git config --global user.name "你的名字" git config --global user.email "你的邮箱" git config --global core.editor "code --wait"这三个配置缺一个，你的commit记录里就会出现一串乱码或者空值，别人用git blame追溯代码时根本找不到责任人。我见过很多团队项目里的提交记录，作者栏写着unknown或者空白，就是因为当年装完Git没配名字和邮箱，后面全成了悬案。
这里有个容易被忽略的细节：user.name和user.email会写进每次提交的元数据里，一旦提交并推送到远程仓库，改起来非常麻烦。公司项目和个人项目的身份如果不同，建议在各自的项目目录下用git config --local单独配置，别拿全局配置一把梭。我之前就吃过这个亏，在公司仓库里用个人邮箱提交了好几次，后来花了不少力气才把历史记录修正过来，得不偿失。
1.2 换行符、中文文件名与.gitignore：最容易踩的三个坑
如果说三件套配置是"让Git能跑"的门槛，那换行符问题就是"让跨平台协作不炸"的关键。Windows默认用CRLF（回车+换行）作为行尾符，而Linux和macOS用LF（换行）。如果团队里有人用Windows有人用macOS，Git会自动帮你把换行符转来转去，结果就会产生一种非常恶心的现象：你只改了一行代码，但git diff显示整个文件都变了，因为Git把所有制表符、回车符都识别成了变更。
我的建议是统一用LF，提交前让Git做自动转换。具体做法是在项目根目录建一个.gitattributes文件，写上固定规则：
* text=auto *.js text eol=lf *.ts text eol=lf *.json text eol=lf *.md text eol=lf这个文件一旦提交，团队所有成员都会自动遵循，比让每个人手动改core.autocrlf配置可靠得多。Windows用户在安装Git时如果被问到Checkout as-is, commit as-is还是Checkout Windows-style, commit Unix-style，建议选第二个Commit Unix-style，配合上面的.gitattributes就能彻底解决换行符问题。
中文文件名乱码也是个高频问题。Git在非UTF-8环境下会把中文文件名转成八进制转义序列，看起来就是一堆\346\226\207\344\273\266这样的乱码。解决办法是设置：
git config --global core.quotepath false这样中文文件名就能正常显示了。另外建议所有文本文件统一用UTF-8编码，别用GBK，不然代码里的中文注释、字符串迟早变成乱码。
.gitignore是另一个入门必踩的坑。很多人一开始不知道要配这个文件，结果把node_modules、target、__pycache__、.idea、.vscode这些依赖目录和IDE配置全提交到了仓库里。等clone下来一执行依赖安装，版本冲突、目录权限错乱各种问题接踵而来。正确的做法是项目初始化那一刻就建好.gitignore，把不该提交的目录和文件全部拦住。
2. Commit Message的规范与价值
2.1 为什么Commit Message决定提交质量
如果让我投票选"Git使用中最被低估的能力"，Commit Message的写作绝对排第一。很多团队管理得看似严格，Code Review、CI/CD、单元测试全都上了，但打开git log --oneline一看，提交信息全是update、fix、改改、commit这种毫无信息量的字眼，整条提交历史就像一部没有标题的电影，不看代码你根本不知道每一帧在讲什么。
Commit Message的价值体现在三个层面。第一是排查问题的效率，线上出了Bug，你用git bisect做二分定位，或者直接翻git log --oneline找嫌疑提交，如果每条提交都写清楚了"做了什么、为什么做"，你顺着标题就能快速缩小范围；第二是Code Review的质量，Reviewer在审核一个提交时，如果Commit Message写得好，他可以先理解意图再读代码，而不是对着几百行diff猜作者的思路；第三是历史追溯的可靠性，半年后你接手一个旧项目，想搞清楚某个模块为什么这么设计，翻到当初那条带详细说明的提交，比去问已经没有耐心的老同事靠谱得多。
我用过一个真实例子来说明。同样是修改登录接口的Bug，糟糕的提交信息是fix，优秀的提交信息是fix(auth): 修复登录接口在Token过期后返回404的问题。前者你还要打开diff才能知道改了哪个文件、动了什么逻辑；后者一眼就能看出修改范围、影响模块和问题现象，甚至直接能用来生成发版说明。
2.2 Conventional Commits规范：一种行业共识的提交格式
Commit Message该怎么写才算规范？社区目前最主流的共识是Conventional Commits，也就是"约定式提交"。它的核心格式是：
<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>格式本身不复杂，但每一部分都有讲究。type是提交类型，必须从下面这些类别中选择，不能自己随便发明：
| type | 含义 | 典型场景 |
|---|---|---|
| feat | 新功能 | 新增一个接口、一个新的页面模块 |
| fix | 修复Bug | 修复某功能报错、数据异常 |
| docs | 文档变更 | 修改README、API文档、注释 |
| style | 格式调整 | 调整缩进、补分号、格式化代码，不改变逻辑 |
| refactor | 重构 | 调整代码结构但不改变外部行为 |
| perf | 性能优化 | 提高加载速度、优化查询效率 |
| test | 测试相关 | 新增用例、修复测试脚本 |
| chore | 构建或辅助工具变动 | 升级依赖、修改CI配置、更新.gitignore |
| build | 构建系统相关 | 修改webpack、vite配置 |
| revert | 回滚提交 | 使用git revert后自动生成 |
scope是影响范围，可以是模块名、组件名、服务名，比如feat(user)表示影响用户模块。subject是简短标题，一句话概括这次提交做了什么，一般不超过50个字符，祈使句、现在时，比如添加用户注册接口而不是添加了用户注册接口或者用户注册接口已添加。
正文部分用来补充"为什么"——为什么这么做、解决了什么问题、有没有副作用。这是很多人忽略的地方。举个实际的例子：
fix(auth): 修复Token过期后接口返回401的问题 用户在Token过期后刷新页面，部分接口会直接返回401，导致页面白屏。 根因是前端在请求拦截器里没有统一处理401响应，刷新Token后没有重放原请求。 解决方案：在拦截器中保存pending请求，刷新Token成功后按队列重放。这条提交的正文交代了问题现象、根因分析、解决方案三个关键信息，将来无论是排查回归问题还是做技术复盘，都能提供充分的上下文。footer用来写关联的Issue编号或Breaking Changes，比如Closes #1234表示关闭issue 1234，BREAKING CHANGE: 修改了Login接口的请求参数结构表示不兼容变更。
2.3 写Commit Message的实操技巧：说"为什么"而不是"改了什么"
我在实际写Commit Message时有一个原则：标题说"做了什么"，正文说"为什么这么做"，如果代码改得很直观，正文甚至可以省略，但"为什么"这个信息不能省。比如你修复了一个Bug，标题写fix: 修复日期格式化在时区为UTC时偏差8小时的问题，正文补充原因是new Date('2024-01-01')会被解析为UTC时间，在东八区显示为前一天；改用dayjs的utc模式解析解决。这样一段正文，比光秃秃的标题有价值得多。
还有一个常见的争议：Commit Message用中文还是英文？我的建议是看团队约定，最好全团队统一。中文的好处是可读性高，所有人都能看懂；英文的好处是和Git官方工具链兼容性最好，很多代码生成工具、Changelog插件对英文格式支持更完善。但最怕的就是中英夹杂，今天写update，明天写修复问题，后天写fix bug，这种混乱状态比纯中文或纯英文都难维护。
写标题的时候还有个技巧：用"如果这个提交回滚了，你能不能用标题向别人解释发生了什么"来检验。如果你自己都觉得解释不清，说明标题太笼统，需要拆分成多个提交或者补充正文。
3. 提交粒度的艺术：让每次提交都成为一件事
3.1 原子性提交：可回滚、可定位、可Review
原子性提交是Git提交实践中仅次于Commit Message的核心原则。这个概念听起来很学术，其实理解起来很简单：一次提交只做一件事。这个"一件事"可以是一个功能的完整实现、一个Bug的连带修复、一次文档的批量更新，但不能是一个文件夹里所有改动的大杂烩。
我见过最典型的反面案例是：开发者在实现功能A的时候，顺便改了两个和A无关的变量名、删了一段无用代码、还更新了一个依赖版本，最后用git add .一把梭全提交了。后果是：Reviewer看diff时无法聚焦，搞不清楚哪些改动是核心逻辑、哪些是附带调整；如果功能A上线后出问题要回滚，连带把代码优化和依赖升级也一起回滚了；以后排查历史时，git blame定位到的提交信息对你理解这段代码毫无帮助。
原子性提交的好处用一句话总结就是：让每次提交都成为独立可理解的最小单元。功能A坏了回滚功能A，不会波及B和C；Review时只看和本提交目标相关的改动，效率翻倍；将来做git bisect定位性能问题时，清晰的边界能让二分查找很快锁定罪魁祸首。我在团队里推行原子性提交后，最直观的感受是代码审查的争议变少了，因为大家都聚焦在同一个逻辑块上，讨论的深度完全不一样。
3.2 用暂存区控制提交内容：git add -p 和它的朋友们
要实现原子性提交，核心武器就是Git的暂存区。很多人对Git的理解停留在"git add 添加文件、git commit 提交"这个最粗粒度的层面，完全没意识到暂存区允许你精确到行地选择要提交的内容。
场景是这样的：你花了半天时间在三四个文件里搞了一个新功能，中途顺手改了一个bug、优化了一段日志打印。现在要提交，怎么办？用git add .会把所有改动混在一起；用git add 文件名也只能按文件粒度控制。真正优雅的方式是用git add -p进入交互式暂存界面，Git会把每个文件的改动拆成一个个代码块（hunk），你逐个决定暂存还是不暂存，甚至可以按s把一个代码块再拆细。
git add -p src/App.js执行后Git会显示第一个代码块的diff，然后等着你输入指令：y暂存这个块，n不暂存，s拆分，e手动编辑。我在实际操作中，e和s用得最多，尤其是当一个函数里既有新功能逻辑又有bug修复时，用s拆成两个提交是最理想的处理。
如果只想暂存指定文件，不要用git add .，推荐用git add src/App.js src/utils/api.js这种显式列表，或者直接交互式选择：
git add -i对于已经暂存但突然发现某个文件不该提交的情况，用git restore --staged 文件名把它从暂存区移回工作区，这个命令等价于老版本Git的git reset HEAD 文件名，注意它不会删除文件本身的改动。
我从SVN时代转过来时，最大的不适应就是"提交前还要先add"这件事。SVN的提交是一步到位的，改完文件直接svn commit。而Git刻意把"选择内容"和"提交内容"分成两步，目的就是让你在提交前有机会思考：这次提交到底应该包含什么、不应该包含什么。这是Git在工程理念上远超SVN的设计之一，很多人却把这一步浪费掉了，养成git add .到手就提交的坏习惯。
4. git commit指令与参数的高频实战用法
4.1 基础命令与参数：从 -m 到 --amend 的完整梳理
先回顾一下提交的基础命令。最常用的就是git commit -m "feat: 添加用户注册接口"，一条命令完成提交并填入标题。多行提交信息（带正文）可以用多个-m：
git commit -m "fix(auth): 修复Token过期后接口返回401的问题" -m "原因是请求拦截器没有统一处理401响应，现在增加了刷新Token后重放请求的逻辑。"git commit -a这个参数我特别提一下：它会自动把所有已跟踪文件的改动暂存并提交，相当于git add -u && git commit。听起来很方便，但对新手其实是个陷阱——它会把你工作区里所有已跟踪文件的修改全部打进这次提交，完全绕开了"选择内容"这步设计。我的建议是：老老实实先git add再git commit，不要偷懒用-a。
git commit --amend是我几乎每天都会用到的参数，它的作用是修改上一次提交。有两种典型场景：一是刚提交完发现漏了一个文件，二是提交完发现Commit Message打错字了。操作方式是：
# 场景一：补充漏提的文件 git add 忘记添加的文件.js git commit --amend --no-edit # 不加 --no-edit 会打开编辑器让你重新填写提交信息 # 场景二：修改提交信息 git commit --amend -m "fix: 正确的提交描述"--amend的本质不是修改原提交，而是创建一个全新的提交替换掉它，所以旧的提交会从当前分支历史中消失。这引出一个最重要的使用禁忌：只允许amend那些还没有推送到远程的本地提交。如果有人已经基于旧提交做了分支开发，你amend之后再强制推送，对方的提交历史和你的就对不上了。
在VS Code里操作Git也很顺手，源码管理面板会清晰显示变更文件列表，勾选需要提交的文件，在上方输入框写提交信息，Ctrl+Enter就能提交。对于习惯Git Bash却不是命令行高手的新人，VS Code这种图形化的方式降低了不少门槛。
4.2 提交后反悔怎么办：reset、revert和reflog的救援组合
提交这件事做得再规范，也难免有反悔的时候。提交完发现有大问题想要撤销，很多人第一反应是git reset --hard，但这是最危险的命令之一，搞不好会让你丢掉一整天的工作成果。理解三个命令的区别比死记参数更重要。
git reset是回退分支指针，有三个模式：--soft只回退commit，保留暂存区和工作区；--mixed（默认）回退commit和暂存区，保留工作区；--hard三者全部回退，工作区的文件改动直接丢弃。如果只是想撤销上一次提交但保留代码改动，用git reset --soft HEAD~1就够了；想连暂存区一起清理，用默认的git reset HEAD~1。
git revert则是反向提交，它会生成一个新提交来"抵消"目标提交的改动，不会改写历史，适合用来撤销已经推送到远程的公共提交。团队协作中如果发现某个提交有严重问题，正确操作是git revert <commit-hash>而不是git reset，因为后者要求强制推送，会让其他成员的本地分支处于不一致状态。
git reflog是最后的救命稻草。它记录了你在本地仓库所有的HEAD移动历史，包括reset、amend、rebase等操作。假设你误执行了git reset --hard HEAD~3，发现代码不翼而飞，只要执行git reflog找到回退前的commit hash，再git reset --hard 那个hash就能恢复如初。团队里如果有人跑来跟我说"我的代码丢了，git push都救不回来"，我第一句话永远是：先看看reflog，八成能找回来。
4.3 Git Hooks与提交前自动化：让机器替你查岗
提交信息规范和原子性提交可以靠自觉，但我更推荐用Git Hooks把它变成"强制标准"。Git在.git/hooks/目录下提供了一系列钩子脚本，其中和提交最相关的是pre-commit和commit-msg。前者在提交前运行，可以执行代码检查；后者在提交信息填写完毕后运行，可以校验信息格式。
一个最简单的pre-commit脚本如下，它会在每次提交前跑指定目录下的测试和lint：
#!/bin/sh echo "Running pre-commit checks..." npx eslint src/ npm run test如果ESLint检查失败，脚本会以非零状态退出，提交自动被拒绝。commit-msg脚本则用来校验格式，比如用正则检查提交信息是否匹配Conventional Commits规范：
#!/bin/sh message=$(cat "$1") if ! echo "$message" | grep -qE '^(feat|fix|docs|style|refactor|perf|test|chore|build|revert)(\(.+\))?: .{1,50}$'; then echo "提交信息不符合规范：请使用 Conventional Commits 格式" exit 1 fi现代前端项目里，更多人会借助Husky工具管理Git Hooks，配合lint-staged实现"只检查本次暂存的代码"。比如在package.json里配置：
{ "husky": { "hooks": { "pre-commit": "lint-staged", "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS" } }, "lint-staged": { "*.{js,ts,vue}": ["eslint --fix", "git add"] } }这套方案的最高价值在于：把质量门禁前移到了每一次提交之前，而不是等到CI阶段才报错。CI报错还能勉强补救，但提交信息不合规范、代码被ESLint一堆警告污染这类问题，在源头拦截下来是最省事的。
5. 提交之外的协作规则：分支策略与提交后协作
5.1 分支命名与工作流：一个适度够用的协作框架
提交完了还要推得出去、合得进来，这依赖团队的分支策略。业界有非常复杂的Git Flow，分支多到新手头皮发麻：master、develop、feature、release、hotfix层层嵌套。有些团队确实需要这种严格流程，但对多数中小型项目和快速迭代的互联网团队，我认为过度设计反而拖慢节奏。我更推荐基于主干开发的简化模型：main（或master）始终保持可发布状态，新功能在短命的分支上开发，完成后通过Merge Request合回主干。
无论采用哪种模型，分支命名都需要规范。我的习惯是类型/描述的结构：feature/用户注册、fix/登录超时、hotfix/支付成功回调错误、chore/升级依赖。这里的描述建议用简短的中文或英文，能让人不看代码就能猜出分支用途。分支名直接和提交标题一样，也是项目历史的一部分。
我在团队里见过一个让人抓狂的命名乱象：有人用test、dev、123、my-branch这种谁都看不懂的名字，分支多的时候根本不知道谁在干什么，合并请求的上下文只能靠猜。定一个简单的命名规范，配合提交信息规范，整个项目的可读性会上一个台阶。
5.2 Rebase还是Merge：提交历史是讲给未来同事的故事
这是Git社区争论最多的话题之一。merge会保留完整的实际开发轨迹，分支上每次提交都记录在案，合并时新增一个merge commit；rebase则会把当前分支的提交"搬"到目标分支最新提交之上，重写提交顺序，让历史看起来像一条直线。
# 合并方式一：merge git checkout main git merge feature/user-register # 生成了一个merge commit，历史保留两条分叉的交汇点 # 合并方式二：rebase git checkout feature/user-register git rebase main # 将feature分支的提交重放到main最新提交之后，历史呈线性我的观点是：使用rebase保持本地开发分支的线性历史，使用merge合入公共主干分支。具体来说，自己开发分支在合并到main之前，先git rebase main把主干上的新提交吸收进来，解决完冲突后用git merge --no-ff合回主干。这样做的好处是：本地提交顺序整齐，定位问题方便；而main分支上的merge commit记录了明确的关口，将来发布时可以快速回看某个版本包含了哪些完整功能。
注意，这条规则有个铁律：不要再重新rebase已经推送到远程且被多人使用的分支，否则会改写公共历史，导致其他人的本地仓库出现一大片冲突，这是团队协作里最严重的错误之一。
5.3 解决冲突的正确姿势：少冲突靠勤快，真冲突靠流程
合并冲突是多人协作绕不开的话题。冲突的本质是两个分支修改了同一处代码，而且Git无法自动判断该保留哪个版本。减少冲突最有效的手段不是"解决得快"，而是"提交得勤、拉取得勤"。在一个功能分支上持续干活超过三天还不同步主干的进度，等合并时大概率积累一堆冲突；如果每天甚至每半天就rebase一次主干，冲突会少很多，而且就算有也容易处理，因为你的改动量小，上下文也还记得清楚。
真遇到冲突时，Git会在冲突文件里插入标记：
<<<<<<< HEAD 当前分支的内容 ======= 被合并分支的内容 >>>>>>> feature/xxx解决冲突的流程是：打开文件，看清楚<<<<<<<和>>>>>>>之间的差异，手动决定保留哪边、两边都留还是重新改写，删除标记行后再git add该文件，最后git commit完成合并。这里有个从SVN时代带过来的旧习惯值得纠正：SVN的冲突解决是"我一改，别人就等着"，而Git的冲突解决是在本地完成，你没有理由慌张，也没有理由觉得解决了冲突就万事大吉——提交后一定要把测试跑一遍，因为手工合并很容易引入逻辑错误。
6. 提交前的自查清单与高频问题排查速查
6.1 提交前五分钟自查清单
这些年在团队里推行Git规范，我慢慢总结出一份提交前自查清单，每次准备git commit前按顺序过一遍，能挡掉90%的低级错误：
第一，跑一遍git status看当前工作区状态，确认没有遗漏的改动文件，也确认没有把开发时的调试代码、日志打印、数据库连接串等敏感信息带进去。git diff再快速扫一眼具体改动，有些问题不看diff根本发现不了，比如误改了几行无关代码、把测试环境的API地址写死进代码里等。
第二，明确本次提交的"一件事"是什么，确认暂存区里的文件改动和这件事相关。不相关的改动请git restore --staged移出去，或者干脆先存放起来，用git stash把无关改动搁置。
第三，运行相关的测试和代码检查。不用全量跑，但至少把当前模块的单元测试、集成测试跑一遍，确保绿色通过。项目配置了lint的也顺手跑一下，避免把ESLint报错提交上去污染代码库。
第四，检查提交信息是否符合Conventional Commits格式，标题是否能概括这批改动，正文是否写清了"为什么"。确认没有把密钥、生产环境地址等敏感信息写进提交信息里。
第五，如果这是修复线上Bug的提交，提交流程走完后第一时间在Commit Message的footer里关联Issue编号，方便团队在问题追踪系统里回溯。
6.2 提交过程高频问题排查速查表
按项目经验整理了一份提交相关问题的速查表，遇到问题直接对号入座：
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
git commit报错说缺少用户名邮箱 | 未配置user.name / user.email | 全局或本地配置后重新提交 |
| 提交进去的内容少了几个文件 | 使用了git add 某文件后漏了其他文件 | git add补齐后git commit --amend --no-edit补充进上一次提交 |
| 提交信息写错了 | - | git commit --amend -m "正确信息"重写提交信息 |
| 把不该提交的文件提交了 | .gitignore配置不全或操作疏忽 | 若未推送：git reset --soft HEAD~1后从暂存区移除文件并重新提交；若已推送：用git rm --cached删除跟踪后提交 |
| 提交后想撤销改动 | 提交内容有问题 | 本地提交用git reset --soft HEAD~1，远端公共提交用git revert <hash> |
误执行git reset --hard丢了代码 | - | git reflog找回原commit hash，git reset --hard <hash>恢复 |
| 合并时冲突太多 | 分支太旧、同步太少 | 先git rebase main解决冲突，再合入主干；以后勤拉取 |
| Windows上文件全部显示为已修改 | 换行符配置不一致 | 在.gitattributes中统一设置eol=lf，让Git处理转换 |
| 中文文件名显示为转义序列 | core.quotepath默认true | git config --global core.quotepath false |
| 提交后CI失败 | 提交前没跑测试、lint | 运行 test/lint 通过后用--amend或新提交修复 |
这份表里有一个我从踩坑中总结出的重要心得：提交的时机宁可早一点、频率宁可高一点。本地开发时每完成一个逻辑闭环就提交一次，比攒到晚上一次性提交稳得多。这样就算某次改动出了岔子，你也只需要处理几十分钟内的代码，而不是面对一整天的混乱。
我个人在实际操作中的体会是，Git本身只是一堆命令，但用好它的关键是建立一种"提交是给别人看的"的心态。你的每一次提交，都是在给未来的自己、未来的同事、未来的维护者写便条。写的时候多花一分钟把信息说清楚，将来排查问题时可能就省下一个下午。这套实践我从团队新人培训一路带到长期项目维护，越用越觉得当初花时间建立这些习惯是值得的。
