Git 常用命令清单：从原理到实战，覆盖开发全场景

干这行十年如果让我从一堆开发工具里必须留一个Git 肯定排在前三名。不管你是写前端、后端、移动端还是搞 DevOps代码管理绕不开它。今天这篇不是官方文档的复读而是我把日常使用频率最高的 Git 命令整理成一份清单结合实际工作中踩过的坑、做过的取舍一次性说清楚每个命令到底解决什么问题、什么时候该用哪个。适合刚学 Git 的新手也适合用了一阵子但某些命令总记不熟的人。这份清单不会把所有冷门参数都列一遍重点在于常用命令怎么用、背后的原理是什么、什么场景下选哪种方案。我见过太多人只会git add .和git commit -m一遇到分支乱了、冲突来了、提交删错了就头皮发麻。所以下面每一节都会给你能直接复制的命令同时解释清楚为什么这么写。1. 内容整体设计与思路拆解1.1 为什么需要一份“常用命令清单”Git 的命令有上百个参数更是不计其数。但真实开发中95% 的时间都在重复使用那二三十个命令。这份清单的核心思路就是从高频操作出发按功能场景分组而不是按字母顺序罗列。比如你正在写代码需要暂存、提交、推送需要开分支、切分支、合并需要看历史、改历史、回滚历史。把这些场景拆开每个场景对应一组命令记忆负担就会小很多。我从实际交付项目的角度重新审视了 Git 的日常使用刚开始接触 Git 的人最大的困惑不是命令太多而是不知道每个命令在什么状态下生效。你commit之后代码去哪了push和pull到底是谁覆盖谁rebase和merge为什么结果不一样所以我在清单里特意把“工作区 - 暂存区 - 本地仓库 - 远程仓库”这条链路画清楚命令只是这条链路上的操作节点。这份清单适合谁我的看法是它适合所有需要用 Git 管理代码的开发者。如果你刚入职不久团队要求你每天用 Git 提交代码但你连revert和reset都分不清这份清单能帮你快速建立正确的操作直觉。如果你已经用 Git 写了一年多但偶尔还会因为pull --rebase和fetch的区别发懵那这份清单就给你一个系统性的查漏补缺机会。1.2 命令分类背后的逻辑真正支撑这份清单的不是命令本身而是我梳理出的五个核心场景初始化与配置init、clone、config这是起点。日常提交add、commit、status、log这是工作流主线。分支与合并branch、checkout、merge、rebase这是多人协作的基石。远程同步remote、push、pull、fetch这是分布式协作的关键。撤销与回滚reset、revert、restore、stash这是出事故时的救生圈。这个分类顺序本身就是在模拟一个开发者的操作路径拿到项目先克隆改完代码提交多需求并行开分支写完推远程出问题回滚。按这个主线来组织清单比按命令首字母排序实用得多。选择这些命令而不是其他冷门命令我遵循两个原则第一是使用频次一个项目周期内至少出现一次的命令才值得进清单第二是可替代性像git show、git diff这种虽然用得不少但我会归入辅助工具不展开讲太细。与其让你背一百个命令不如把二十个核心命令用透。2. 核心细节解析与实操要点2.1 初始化与配置所有操作的起点一个新项目或者一个刚拉到本地的老项目第一件事就是确认 Git 环境。我通常会先做两件事检查版本和检查全局配置。git --version git config --global user.name 你的名字 git config --global user.email 你example.com git config --list这里有个特别容易踩的坑如果你在某个项目里提交后发现作者名不对多半是没配全局变量或者某个仓库里配了个不同的局部变量。局部配置优先级高于全局配置所以排查时用git config --list --show-origin可以看清楚每个配置是从哪个文件来的。初始化一个仓库用git init克隆远程仓库用git clone url。很多人分不清这两者的适用场景init是你本地从零开始的项目clone是远程已有项目你把它复制到本地。克隆下来后你不需要再init因为它自带完整 Git 历史。配置这块还有一个细节换行符处理。跨平台协作时不同操作系统的换行符会导致整个文件显示为已修改。我建议在项目根目录添加.gitattributes文件统一处理这类问题。虽然这不是一条命令能做到的但配置好一劳永逸比每次用git diff瞎猜强得多。2.2 日常提交链路暂存区要重视提交操作看起来简单实际上面临最核心的抉择是到底把所有改动一次性add进去还是按逻辑拆成多个提交。我会把git add看作一个“组装”动作你决定把哪些改动放进这次提交。git status git add file1 file2 git add . # 注意这会暂存所有改动包括删除 git commit -m 你的提交信息git add .是懒人最爱但也是隐患来源。如果你动了不该动的文件比如本地配置文件一不注意就提交上去了。我建议用git add -p逐块审查暂存内容虽然慢一点但能避免很多团队事故。另外git status应该成为肌肉记忆每次提交前至少看一眼。提交信息怎么写我团队内部约定“动词 对象 原因”例如fix(login): 修复异常字符导致的登录失败。这样看历史日志时能快速定位改动意图。很多人不重视提交信息等要回滚代码时翻日志才发现完全看不懂那时就晚了。2.3 分支管理与合并团队协作的命脉分支是 Git 最强大的特性没有之一。创建分支的命令非常直接git branch feature/xxx # 创建分支 git checkout feature/xxx # 切换分支 git checkout -b feature/xxx # 创建并切换新版本 Git 推荐git switch和git restore来做分支切换和文件回滚语义更清晰。我在实际项目中常遇到的问题不是不会创建分支而是分支多了之后不知道哪些已合并、哪些还能删。git branch --merged和git branch --no-merged可以帮你快速筛出来。合并的两个主要方案是merge和rebase。merge保留完整历史生成一个合并提交rebase重写历史让提交记录成一条直线。就单个团队而言我建议明确规则公共分支用merge个人功能分支用rebase再合回主分支。这样历史清晰不会出现一堆分叉节点。合并冲突是必须面对的现实。基本流程是先git status看冲突文件然后编辑文件去掉、、标记再git add和git commit。不要慌冲突不是坏事情它只是说明两边的改动确实有重合。解决冲突的技术含量不高但对代码逻辑的理解要求不低。3. 实操过程与核心环节实现3.1 从零到首次提交一次干净的起步假设你接到了一个新模块的开发任务按我习惯的完整流程来操作mkdir project-x cd project-x git init git config --local user.name 你的名字 echo # Project X README.md git add README.md git commit -m chore: 初始化项目 git branch -M main git remote add origin https://example.com/project-x.git git push -u origin main注意git branch -M main这是把当前分支重命名为main。很多旧项目默认分支叫master新项目建议从第一天就用main避免后续因默认分支名不一致带来的困惑。git push -u的-u参数很关键它把本地分支和远程分支建立上游跟踪关系之后你直接输git push就能推不用每次带远程名。首次提交的粒度我建议越小越好。好多人在项目第一周就把所有代码塞进一个提交然后后续想单独回滚某个功能就束手无策。我第一次带团队时就犯过这错最后被迫用git reset翻历史折腾了一下午。所以初始化只提交基础设施文件业务代码拆开逐步提交。3.2 分支合并与冲突解决一次完整的实战记录前几天我刚处理完一个模拟项目 X 的冲突场景可以拿来复盘。主分支main上改了一个公共函数功能分支feature/payment上也改了这个函数。合并时直接报冲突。git checkout main git pull git checkout feature/payment git merge mainGit 会提示Auto-merging失败然后列出冲突文件。我用git status定位到src/payment.js。打开文件看到两处冲突标记一块是别人保留了旧参数一块是我加了新的校验逻辑。处理的决策是两边改动都必要那就按逻辑顺序手工合并两段内容删掉所有冲突标记。解决后依次执行git add src/payment.js git commit -m merge: 合并 main 到 feature/payment这里有个经验解决冲突后先跑一遍本地测试不要急着提交。我见过太多人冲突标记删干净就提交结果编译直接挂了。Git 只负责文本层面的合并它并不知道你代码逻辑是否正确。所以合并后的验证环节不能省。3.3 撤销与回滚三个方案怎么选撤销是 Git 里最容易被误用的部分。我梳理了几个实战场景刚提交了但发现提交信息写错了git commit --amend -m 新信息用来修改最后一次提交。提交进了错误的提交记录想保留历史但撤销改动用git revert commit它会生成一个反向提交是安全操作。想彻底废弃某几个提交重写历史git reset --hard target危险操作操作前确认没有别人在用。我实际写代码时的选择逻辑是如果对象是公共分支上已经推送的提交绝不使用reset因为会破坏别人本地的历史改用revert最安全。如果对象是个人本地分支且还没推过用reset清理掉错误提交干净利落。还有一个常被忽略的命令是git stash。当你手头改了一半突然要切分支修个紧急问题直接切换会带回未提交的改动。此时git stash暂存起来切分支修完再切回来git stash pop找回改动。这个命令帮我避免了无数次改动丢失的惨剧。4. 常见问题与排查技巧实录4.1 提交信息写错了怎么办这是刚用 Git 的人问得最多的一个问题。如果只是最后一次提交直接git commit --amend -m 正确的信息即可。如果你的提交已经推送到了远程就需要额外处理因为这相当于重写了历史。个人分支上可以直接push --force公共分支则需要确认团队规则很多团队严禁强制推送。我建议的排查顺序先看git log确认你要改的提交是不是最新一条再确认你是否推送过。如果推送过并且只有你在用这条分支强制推没问题如果还有其他开发者基于这个分支工作就别改新增一个提交来修正即可。4.2 误删分支的恢复删分支前我常会运行git branch -d它只删除已合并的分支如果分支未合并会直接报错拒绝删除。但如果你加了-D强制删除而事后发现自己还需要那个分支怎么办别慌Git 会留下一个短暂的引用。先用git reflog查看操作记录找到删除分支之前的提交哈希然后通过那个哈希重新创建分支。这个方法我实测过很多次恢复率极高。所以reflog是每个开发者都必须掌握的命令它在关键时刻比任何备份方案都管用。4.3 拉取远程代码被拒绝是怎么回事最常见报错是non-fast-forward意思是远程分支有了你本地没有的提交而本地也有远程没有的提交两边分叉了。此时有人会直接git pull结果可能产生一个合并提交甚至冲突。更推荐的方案是git fetch git rebase origin/main git pushfetch只更新远程引用不改变本地工作区比pull安全得多。之后rebase把本地提交放在远程提交之后让历史保持线性。如果 rebase 冲突按第 3.2 节的方式解决。发现拉不下来时先别乱动看清分叉点是哪几个提交再操作。4.4 独家避坑技巧丢过数据才明白这几条结合多年踩过的坑我总结几条独家技巧希望能让你少走弯路提交前做完整的 diff 审查git diff看暂存区改动不要凭印象提交。经常会出现误改了无关文件的情况。每次切分支前先git status确认干净如果还有未提交改动要么提交要么 stash不要硬切。推送前先拉取养成git pull --rebase的习惯让同步操作的行为可预期避免自动产生本地合并。给git reset设置心里防线只在本地分支上使用如果必须用在公共分支上先做好备份甚至可以先git branch backup/xxx创建一个备份分支。多熟悉git reflog所有因为误操作丢失的提交基本都能从这里找回来。它记录的是本地 HEAD 的移动轨迹比你的记忆可靠。这些技巧里最后一条价值最大。有一次我在某个项目上错误地reset --hard清掉了两天的改动当时差点重写代码后来想起来用git reflog发现上次的提交哈希还在直接恢复了出来。从那时候起我就养成了习惯危险操作前先看一眼reflog的位置给自己留一条后路。最后再分享一个小技巧每当换新电脑或者重装系统我都习惯把这份命令清单的后半部分就是上面那些避坑提示过一遍。别嫌啰嗦真正的生产力往往不在创建分支、提交代码这些顺滑操作上而在于那些出错之后能否快速恢复的能力。把常用命令和它们的“为什么”记住你就能在团队里比其他同学更沉着地处理各种代码事故。