1. 项目概述为什么你需要一份自己的Git命令清单干了这么多年开发我敢说没有哪个工具能像Git这样既让人爱不释手又让人偶尔恨得牙痒痒。爱它是因为它强大的版本控制能力让团队协作和代码管理变得井井有条恨它是那些复杂的命令和参数总是在最需要的时候从脑子里溜走。你是不是也经常这样想合并分支却忘了是git merge还是git rebase想查看某次提交的改动却记不清git log后面该跟什么参数或者在紧急修复线上Bug时面对冲突手足无措这就是为什么每个开发者无论新手还是老鸟都需要一份属于自己的、经过实战检验的Git常用命令清单。它不是一个简单的命令罗列而是一套基于真实工作流、融入了大量“血泪教训”的操作指南。网上的清单很多但往往要么过于简略要么就是命令的简单堆砌缺少了“为什么”和“什么时候用”的灵魂。今天我就结合自己十多年的经验为你梳理一份真正能“救命”的Git命令集合并告诉你每个命令背后的逻辑和那些官方文档里不会写的坑。这份清单的目标很明确让你在80%的日常开发场景中能快速找到正确的命令并理解其原理在剩下的20%复杂场景里为你提供清晰的排查思路和解决方案。我们不仅要知道“怎么做”更要明白“为什么这么做”。2. Git核心概念与工作流再理解在开始罗列命令之前我们必须先统一“语言”。很多Git操作之所以混乱是因为对几个核心区域的理解有偏差。网上那张经典的“工作区、暂存区、本地仓库、远程仓库”图你可能看过很多遍但我想用更贴近实战的方式解释一下。2.1 四个核心区域与你的日常工作想象一下你正在开发一个新功能工作区 (Workspace)就是你电脑上正在编辑的代码文件所在的文件夹。你在这里用IDE或编辑器敲代码、增删文件。这里的改动是“未跟踪”或“已修改”状态。暂存区 (Stage/Index)这是一个准备区。你把工作区里觉得“阶段性完成”或“可以提交”的文件通过git add命令放进来。暂存区的作用是让你可以精细地控制一次提交中包含哪些改动而不是一股脑把所有修改都提交。这是Git区别于其他版本控制系统如SVN的一个关键设计。本地仓库 (Local Repository)当你执行git commit后暂存区的内容就被打包成一个永久的“快照”即一次提交存入本地仓库。这个仓库就在你项目的.git隐藏文件夹里。所有提交历史、分支信息都安全地存储在这里。在联网之前你的所有操作都可以在这里完成。远程仓库 (Remote Repository)就是GitHub、GitLab、Gitee等平台上的那个仓库。它是团队协作和代码备份的中心。通过git push将本地提交同步上去通过git pull或git fetch把别人的工作拉下来。一个典型的日常流程是工作区编辑 - git add到暂存区 - git commit到本地仓库 - git push到远程仓库。2.2 分支Git的“平行宇宙”分支是Git的杀手级特性。你可以把主分支如main或master想象成稳定的生产线。当你要开发新功能或修复Bug时最好的做法不是直接在生产线上捣鼓而是从主分支拉出一条新的“实验线”这就是创建新分支git branch feature-xxx。好处你在新分支上随便折腾无论代码写成什么样都不会影响主分支的稳定性。功能完成后通过合并merge或变基rebase操作将这条“实验线”的成果整合回主生产线。核心命令git branch查看/创建分支git checkout或git switch切换分支git merge合并分支。理解这些概念后命令就不再是冰冷的字符串而是你在不同区域、不同分支间穿梭的“传送门”。下面我们就按实际工作场景来梳理这些“传送门”的使用方法。3. 日常开发高频命令全解析这一部分是你在单兵作战或小步快跑时最常打交道的命令。掌握它们你就能独立完成90%的本地开发任务。3.1 仓库初始化与克隆一切始于一个仓库。git init在当前目录创建一个全新的Git仓库。这是你从零开始一个项目的第一步。执行后当前目录下会生成一个.git隐藏文件夹所有版本信息都将存储于此。# 进入你的项目目录 cd my-awesome-project # 初始化Git仓库 git init注意对于已有项目切勿在子目录中再次执行git init这会导致嵌套的Git仓库引发混乱。git clone url这是更常见的起点。将远程仓库如GitHub上的项目完整地复制到本地包括所有历史记录和分支。# 克隆一个远程仓库 git clone https://github.com/username/repository.git # 克隆到指定目录 git clone https://github.com/username/repository.git my-local-folder实操心得使用git clone时默认会拉取远程仓库的HEAD分支通常是main或master。克隆完成后会自动创建一个指向远程origin的跟踪分支。3.2 状态查看与差异比较搞清楚“我在哪我改了啥”在提交前务必先看清楚。git status你的第一道安全检查。它会清晰地告诉你哪些文件被修改了但还没暂存红色。哪些文件已经暂存准备提交绿色。是否有新文件未被跟踪。当前处于哪个分支。$ git status On branch main Your branch is up to date with origin/main. Changes not staged for commit: (use git add file... to update what will be committed) (use git restore file... to discard changes in working directory) modified: src/utils.js # 红色已修改但未暂存 Changes to be committed: (use git restore --staged file... to unstage) modified: README.md # 绿色已暂存养成频繁使用git status的习惯能避免许多误操作。git diff查看具体的改动内容。git diff比较工作区和暂存区的差异。即你改了但还没git add的内容。git diff --staged(或git diff --cached)比较暂存区和上一次提交(HEAD)的差异。即你已经git add了准备提交的内容。git diff HEAD比较工作区和上一次提交(HEAD)的差异。这是你自上次提交以来所有改动的总和。# 查看工作区与暂存区的差异 git diff # 查看暂存区与上次提交的差异 git diff --staged # 查看工作区与上次提交的总差异 git diff HEAD3.3 文件操作添加、提交与忽略这是构建提交的核心步骤。git add将工作区的改动送入暂存区。# 添加指定文件 git add src/component.js # 添加当前目录下所有改动包括新文件 git add . # 添加所有已跟踪文件的改动不包括新文件适合只想提交修改不提交新文件时使用 git add -u # 交互式添加可以分块(hunk)选择文件中的部分改动进行暂存非常精细 git add -p避坑指南慎用git add .尤其是在根目录。它会把所有改动包括你不想提交的配置文件、编译产物都加进去。先用git status看清楚再用git add 具体文件更安全。git add -p是高级用法在拆分提交时非常有用。git commit将暂存区的内容打包成一个永久的提交记录。# 最常用的提交方式-m后面跟提交信息 git commit -m feat: 添加用户登录功能 # 如果不加-m会打开默认编辑器如Vim让你编写更详细的提交信息 git commit # 提交时自动将所有已跟踪文件的改动add进来并提交跳过git add步骤对新文件无效 git commit -a -m fix: 紧急修复一个bug # 修改上一次提交的信息前提是还没push到远程 git commit --amend -m 新的提交信息 # 修改上一次提交并加入新的文件改动 git add forgotten-file.js git commit --amend --no-edit # --no-edit表示不修改提交信息提交信息规范写清晰的提交信息是专业素养。推荐使用类似“类型: 描述”的格式如feat:新功能、fix:修复、docs:文档、style:格式、refactor:重构、test:测试、chore:构建/工具。这便于后续生成Change Log。.gitignore文件这不是一个命令但至关重要。它告诉Git哪些文件或目录应该被忽略不纳入版本控制。比如编译产物node_modules/,dist/、IDE配置文件.vscode/,.idea/、本地环境变量文件.env.local等。项目一开始就应该创建它。# .gitignore 示例 node_modules/ dist/ .env .DS_Store *.log3.4 分支管理高效并行开发的基石git branch分支的查看与管理。# 查看本地分支当前分支前有*号 git branch # 查看所有分支包括远程分支 git branch -a # 查看远程分支 git branch -r # 创建新分支 git branch feature-branch # 删除已合并的分支安全删除 git branch -d feature-branch # 强制删除分支即使未合并慎用 git branch -D hotfix-branchgit checkout与git switch切换分支。git checkout是老牌命令功能多切换分支、恢复文件但也容易混淆。# 切换到已存在的分支 git checkout main # 创建并切换到新分支经典用法 git checkout -b new-featuregit switch是Git 2.23版本引入的更专注的命令推荐使用语义更清晰。# 切换到已存在的分支 git switch main # 创建并切换到新分支 git switch -c new-featuregit merge合并分支。将指定分支的更改合并到当前分支。# 确保你在目标分支比如main git switch main # 将feature-branch合并到main git merge feature-branch合并冲突如果两个分支修改了同一文件的同一区域就会产生冲突。Git会标记出冲突内容你需要手动编辑文件解决冲突然后git add标记为已解决最后git commit完成合并。git rebase变基。另一种整合分支的方式它会将当前分支的提交“重新播放”在目标分支的最新提交之上从而得到一条更线性的历史。# 在feature分支上将其变基到最新的main分支上 git switch feature git rebase main重要警告不要在公共分支如main上执行rebase。Rebase会重写提交历史如果这个历史已经推送到远程并被他人使用会导致严重的同步问题。Rebase通常用于整理本地尚未推送的提交。3.5 查看历史与追溯时光机git log查看提交历史。参数繁多是信息检索利器。# 基础查看按时间倒序 git log # 简洁模式只显示提交哈希和标题 git log --oneline # 图形化显示分支合并历史 git log --graph --oneline --all # 查看最近5次提交 git log -5 # 查看指定文件的修改历史 git log --follow -p src/file.js # 按作者筛选 git log --authoryourname # 按提交信息关键词搜索 git log --grepbugfixgit show commit-hash查看某一次提交的详细信息包括具体改了哪些内容。git show a1b2c3dgit blame file“问责”命令。查看指定文件的每一行最后一次是由谁在哪个提交中修改的。在追查Bug来源时非常有用。git blame src/utils.js4. 远程协作与同步命令详解当你的代码需要与团队共享或者从中央仓库获取更新时就需要下面这些命令。4.1 远程仓库管理git remote管理远程仓库地址的别名通常叫origin。# 查看远程仓库信息-v显示地址 git remote -v # 添加一个远程仓库命名为upstream常用于fork的项目同步原仓库 git remote add upstream https://github.com/original/repo.git # 修改远程仓库地址比如从HTTPS切换到SSH git remote set-url origin gitgithub.com:username/repo.git # 删除远程仓库连接 git remote remove upstream4.2 拉取与推送与远程仓库对话git fetch“只下载不合并”。从远程仓库获取所有分支的最新提交和历史但不会自动合并到你的工作区。它让你知道远程发生了什么。git fetch origin # 查看远程分支更新情况 git log origin/main --onelinegit pull“下载并合并”。相当于git fetchgit merge。它将远程分支的更新拉取下来并直接合并到当前本地分支。git pull origin main最佳实践在pull之前先commit或stash你本地的改动避免冲突。更推荐使用git pull --rebase它会在拉取后使用rebase而非merge来整合你的本地提交保持历史更整洁。git push将本地分支的提交推送到远程仓库。# 将当前分支推送到远程origin的同名分支 git push origin # 明确指定本地分支和远程分支 git push origin feature-branch:feature-branch # 首次推送并建立本地分支与远程分支的追踪关系 git push -u origin feature-branch # 强制推送会覆盖远程历史极其危险仅在特定情况下使用如rebase后 git push --force-with-lease # 比--force更安全会检查远程是否已有你未知的提交强制推送警告git push --force是破坏性操作除非你百分百确定远程分支只有你一人在操作比如你个人的特性分支否则不要用。--force-with-lease是更安全的选择。5. 高阶操作与“后悔药”撤销与重置人非圣贤孰能无过。Git提供了强大的“后悔药”但吃错药后果更严重。5.1 撤销工作区的修改git restore file(Git 2.23) 或git checkout -- file(旧版)丢弃工作区中某个文件的修改将其恢复到最近一次git add或git commit时的状态。# 恢复单个文件 git restore src/file.js # 恢复所有文件危险会丢失所有未暂存的修改 git restore .注意这个操作不可逆一旦执行工作区的改动就永久丢失了。5.2 撤销暂存区的修改取消addgit restore --staged file或git reset HEAD file将已经git add到暂存区的文件移回工作区但保留工作区的修改内容。# 误将文件add了想拿出来重新修改 git restore --staged src/file.js # 此时src/file.js的修改还在工作区但不在暂存区了5.3 重置提交历史谨慎git reset重置当前分支的HEAD指针到指定的提交。有三种模式--soft只移动HEAD指针不改变暂存区和工作区。你之前的修改都还在暂存区。适合重新组织提交。# 将HEAD指向上一个提交但修改保留在暂存区 git reset --soft HEAD~1--mixed(默认)移动HEAD指针并重置暂存区但不改变工作区。你之前的修改变成了未暂存状态。这是最常用的撤销git add和git commit的方式。# 撤销上一次提交并且将修改放回工作区 git reset HEAD~1 # 或 git reset --mixed HEAD~1--hard危险移动HEAD指针并重置暂存区和工作区。所有未提交的修改包括工作区和暂存区都将被永久丢弃。# 彻底回退到上一个提交丢弃所有本地修改 git reset --hard HEAD~1 # 强制将本地分支与远程origin/main同步丢弃所有本地提交和修改 git fetch origin git reset --hard origin/main核心原则git reset --hard是核武器只在确定要抛弃一切时使用。对于已经推送到远程的提交尽量避免使用reset而应该使用git revert。git revert commit-hash创建一个新的提交来“反向操作”指定的旧提交从而安全地撤销更改。这是撤销已公开提交的推荐方法因为它不会重写历史。# 撤销某次提交a1b2c3d git revert a1b2c3d # 这会打开编辑器让你编写revert的提交信息然后生成一个新的提交5.4 暂存临时工作git stash当你需要紧急切换分支但手头的工作还没完成、不想提交时git stash是你的救星。git stash或git stash push -m “message”将当前工作区和暂存区的修改保存到一个临时堆栈中并将工作区恢复到干净状态。git stash list查看所有的储藏列表。git stash pop应用最近一次的储藏并从堆栈中删除它。git stash apply stash{n}应用指定的储藏如stash{0}但不从堆栈删除。git stash drop stash{n}删除指定的储藏。# 正在feature分支上开发需要切到main修bug git stash push -m “临时保存新功能开发” git switch main # ... 修完bug并提交 git switch feature git stash pop # 恢复刚才的修改6. 实战问题排查与进阶技巧理论说再多不如实战踩坑。下面是我总结的几个高频问题场景和解决思路。6.1 常见问题速查表问题场景可能原因排查命令与解决思路fatal: not a git repository当前目录不是Git仓库。pwd确认位置cd到正确的项目根目录。error: failed to push some refs远程有本地没有的新提交。先执行git pull --rebase解决可能的冲突后再git push。合并冲突 (Merge Conflict)两个分支修改了同一文件的同一部分。1. 编辑冲突文件搜索,,标记。2. 解决后git add file标记已解决。3.git commit完成合并。提交了错误文件或信息提交到了本地仓库但未推送。- 修改上次提交信息git commit --amend- 撤销上次提交保留修改git reset HEAD~1- 彻底撤销上次提交git reset --hard HEAD~1(危险)误删了未提交的文件工作区文件被删除。从最近一次提交中恢复git checkout -- file或git restore file想回到某个历史版本需要重置历史。1. 查看历史git log --oneline2. 软重置保留修改git reset --soft commit-hash3. 硬重置丢弃修改git reset --hard commit-hash(危险)分支混乱想重来本地分支状态混乱。1. 备份重要修改git stash2. 强制与远程同步git fetch origin git reset --hard origin/main6.2 进阶技巧让Git更顺手配置别名 (Alias)为长命令设置短别名极大提升效率。编辑~/.gitconfig文件全局或项目下的.git/config。[alias] co checkout br branch ci commit st status lg log --graph --oneline --all last log -1 HEAD unstage restore --staged配置后就可以用git st代替git statusgit lg查看漂亮的历史图了。使用.gitconfig统一配置设置全局用户信息、默认编辑器、颜色输出等。git config --global user.name Your Name git config --global user.email your.emailexample.com git config --global core.editor code --wait # 使用VSCode作为提交信息编辑器 git config --global color.ui auto理解HEAD,^,~HEAD指向当前分支的最新提交。HEAD~1或HEAD^指向上一个提交。HEAD~2指向上两个提交。HEAD^2在合并提交中指向第二个父提交常用于查看合并进来的分支。善用git reflog这是你的“终极后悔药”。它记录了本地仓库中所有HEAD和分支引用的移动历史。即使你reset --hard错了只要操作是本地发生的通常都能用reflog找回来。git reflog # 找到误操作之前的那个commit hash git reset --hard a1b2c3d7. 总结与个人工具箱Git的命令远不止这些但上面列出的已经覆盖了从入门到精通的绝大部分场景。我的建议是不要试图一次性记住所有命令。把这份清单当成你的“瑞士军刀”参考手册。我个人的日常工具箱其实就浓缩在几个高频动作里每日开工git status看状态git pull --rebase拉最新代码。开发中git add -p精细暂存git commit -m “...”写清楚信息git stash临时切换。功能完成git switch main,git pull --rebase,git switch feature,git rebase main变基保持线性历史解决冲突git push。出问题时git diff看改了啥git log --oneline看历史git reflog找后悔药。最后再分享一个我用了很多年的习惯为每一个功能或修复创建一个独立的分支。这能让你的提交历史清晰得像一本好书回滚、排查、协作都无比轻松。Git的强大正在于它赋予了你掌控代码历史的能力而这份能力就从熟练使用这些命令开始。多练多踩坑你自然会形成自己的肌肉记忆和最佳实践。