1. 从“能用”到“高效”为什么Mac开发者必须掌握终端Git如果你在Mac上做开发无论是前端、后端还是移动端Git几乎是你每天都要打交道的工具。很多人习惯用图形化客户端比如Sourcetree、GitHub Desktop或者IDE内置的Git工具。这没问题它们直观、易上手能帮你完成大部分基础操作。但当你遇到复杂的合并冲突、需要追溯某行代码的历史、或者想批量操作多个分支时图形界面的局限性就暴露出来了——要么功能藏得太深要么干脆没有。这时终端里的Git命令就成了你手中最锋利的手术刀。我见过不少开发者对终端Git的认知停留在git add、git commit、git push三板斧。这当然能工作但就像只学会了开车却不懂怎么保养和应对突发故障。真正高效的协作和问题排查往往依赖于那些不那么“常用”的命令。比如当线上代码出问题时你能快速用git bisect定位到引入问题的具体提交吗当需要清理本地一堆试验性的分支时你是一个个手动删除还是用一行命令搞定这篇文章不是一份冷冰冰的命令手册。我会结合自己多年在Mac上使用Git的经验从日常开发的工作流出发梳理那些真正能提升效率、解决实际问题的命令。我会告诉你每个命令在什么场景下用为什么这么用以及我踩过哪些坑。我们的目标不是记住所有命令而是建立一套肌肉记忆让你在终端里操作Git时感觉就像在跟一个老朋友对话一样自然流畅。2. 基石配置与初始化——打造你的专属工作环境在开始任何炫酷的操作之前我们需要把地基打牢。Git的配置决定了你的使用体验从提交者信息到默认行为都藏在这里。2.1 全局配置你的身份标识第一次在Mac上使用Git你需要告诉Git你是谁。这通过设置用户信息来实现git config --global user.name 你的姓名 git config --global user.email 你的邮箱这里的--global选项意味着这个配置对你这台电脑上的所有Git仓库都生效。为什么邮箱很重要因为GitHub、GitLab等平台会用它来关联你的提交和你的账户。如果你的公司邮箱和个人邮箱不同记得在公司的项目里可能需要覆盖这个全局设置。一个我强烈建议的配置是设置默认分支名。过去Git的默认初始分支叫master现在社区更倾向于使用main。你可以一劳永逸地修改它git config --global init.defaultBranch main这样以后每次执行git init创建新仓库时初始分支就是main了。2.2 别名配置把长命令变“快捷键”Git命令有时候很长比如查看带提交图的日志git log --oneline --graph --all。每次敲这么一长串太麻烦了。这时别名Alias就是你的救星。你可以把它映射成一个简短的命令。git config --global alias.lg log --oneline --graph --all --decorate配置之后你只需要输入git lg就能看到漂亮的图形化提交历史了。我个人的常用别名还有git config --global alias.co checkout # git co 切换分支 git config --global alias.br branch # git br 查看分支 git config --global alias.ci commit # git ci 提交 git config --global alias.st status # git st 查看状态 git config --global alias.unstage reset HEAD -- # git unstage file 撤销暂存注意别名是个人偏好没有标准答案。但建议团队内部可以共享一套常用的别名配置能提升协作时看对方命令的熟悉度。2.3 仓库初始化与克隆一切的开始有两种主要方式获得一个Git仓库。第一种是从头创建mkdir my-project cd my-project git init执行git init后当前目录下会生成一个隐藏的.git文件夹这就是Git的“数据库”和“控制中心”。所有版本信息都存储在这里。更常见的是第二种从远程仓库克隆。这通常是你参与一个已有项目的第一步。git clone https://github.com/username/repository.gitgit clone命令不仅会下载所有代码还会自动将远程仓库的地址命名为origin并拉取所有分支信息虽然默认只检出main分支。如果你想克隆到指定目录可以在后面加上目录名git clone url my-local-folder。这里有一个细节克隆时默认只拉取远程仓库的默认分支如main。如果你想一次性获取所有分支的最新信息可以在克隆后执行git fetch --all。但更常见的做法是需要哪个分支再单独切换和拉取避免本地信息过载。3. 日常开发循环提交、撤销与状态管理这是Git最核心的使用场景一个典型的循环是修改代码 - 查看状态 - 暂存更改 - 提交 - 推送。3.1 洞悉一切git status是你的仪表盘在做出任何操作前先看状态。git status会告诉你当前在哪个分支。相对于这个分支有哪些文件被修改了Changes not staged for commit。有哪些文件已经通过git add暂存了Changes to be committed。有没有未被跟踪的新文件Untracked files。它的输出非常直观。但我更喜欢用git status -s或git status --short它会给出一个紧凑的视图M README.md A new-file.txt ?? untracked-file.js第一列是两个字符的状态码。第一个字符表示暂存区Staging Area的状态第二个字符表示工作区Working Directory的状态。常见的有M文件已修改但未暂存。M文件已修改且已暂存。A新文件已暂存。??未被Git跟踪的新文件。这个视图让你对仓库的变更一目了然尤其是在文件较多的时候。3.2 精准暂存git add的艺术很多人习惯git add .一把梭把所有改动都暂存。这很危险因为很容易把调试的日志、临时文件一起提交进去。更推荐的做法是精准暂存。git add file暂存特定文件。git add directory暂存某个目录下的所有更改。git add -p或git add --patch这是神器。它会交互式地让你选择每一个代码块hunk是否要暂存。你可以仔细审查每一处改动确保这次提交只包含逻辑上相关的变化。这对于保持提交历史的清晰至关重要。3.3 撰写有意义的提交git commit暂存之后就是提交。git commit会打开默认编辑器Mac上通常是Vim或nano让你填写提交信息。信息格式通常第一行是简短摘要不超过50字符空一行然后是详细描述。如果你提交信息很简单可以直接用-m参数git commit -m “修复了用户登录时的空指针异常”一个关键技巧git commit -v。这个-v(verbose) 选项会在编辑器中同时显示你本次提交所做的所有代码差异。在写提交描述时看着这些改动你能写出更准确、更有上下文的信息。3.4 常见的“后悔药”撤销操作人总会犯错Git给了你多次“后悔”的机会但时机不同用的命令也不同。撤销暂存Unstage当你用git add把文件加入暂存区后反悔了。git reset HEAD file # 旧式写法依然有效 git restore --staged file # Git 2.23版本后推荐的新命令语义更清晰这个操作只把文件从暂存区挪回工作区文件的修改内容还在。撤销工作区的修改你改了一个文件但改乱了想彻底丢弃这些修改回到最后一次提交的状态。git checkout -- file # 旧式写法 git restore file # 新命令警告这个操作不可逆本地修改会被直接覆盖请确保你真的不需要这些改动了。修改最后一次提交提交完后发现漏了文件或者提交信息写错了。git add forgotten-file git commit --amend--amend不是新增一个提交而是修改上一次提交。它会用新的暂存内容替换掉旧的提交。注意如果已经推送到远程强制修改已共享的历史可能会给协作者带来麻烦。3.5 推送到远程git push本地提交只存在于你的电脑上。需要推送到远程仓库如GitHub才能与他人协作。git push origin main这条命令将本地的main分支推送到远程仓库origin的同名分支。当你第一次推送本地分支时远程可能还没有这个分支需要建立追踪关系git push -u origin feature-branch # 或 git push --set-upstream origin feature-branch-u参数设置了上游upstream分支之后在这个分支上直接输入git push即可Git就知道要推送到哪里。4. 分支与合并并行开发的基石分支是Git的“杀手级”功能它让你能安全地隔离不同功能或修复的开发。4.1 分支的创建、切换与查看git branch列出所有本地分支当前分支前会有一个*号。git branch -a列出所有分支包括远程分支以remotes/开头。git branch branch-name基于当前所在分支创建一个新分支。git checkout branch-name切换到指定分支。git checkout -b new-branch-name创建并立即切换到新分支。这是最常用的组合命令。这里有个现代命令git switch它是Git 2.23引入的专门用于切换分支语义比git checkout更清晰因为checkout还能用来恢复文件。git switch branch-name切换分支。git switch -c new-branch-name创建并切换分支。4.2 合并与变基整合代码的两种哲学当你完成一个功能分支的开发需要把它合并回主分支时有两种主要方式。1. 合并Merge这是最直接的方式它会创建一个新的“合并提交”保留两个分支的历史。git switch main git merge feature-branch如果合并过程中没有冲突Git会自动完成。如果有冲突你需要手动解决冲突文件然后git add标记已解决最后git commit完成合并提交。合并的优点是历史清晰能真实反映开发过程。缺点是当分支很多时历史线会变得像一张纠结的网。2. 变基Rebase变基更像是“重演”。它把你当前分支的提交在目标分支如main的最新提交上重新应用一遍。git switch feature-branch git rebase main变基完成后feature-branch的历史会变成一条直线仿佛所有工作都是基于最新的main分支完成的。然后再切回main进行快进合并fast-forwardgit switch main git merge feature-branch变基的优点是项目历史是一条干净的直线更容易阅读。但有一个黄金法则只对尚未推送到远程仓库的本地提交进行变基。如果你变基了已经共享的提交会重写历史给协作者带来同步的噩梦。4.3 处理合并冲突冲突不可避免。当Git无法自动合并时冲突文件里会有类似这样的标记 HEAD 这是主分支上的代码 这是特性分支上的代码 feature-branch你需要手动编辑文件保留你想要的部分删除这些标记,,。解决完所有冲突文件后git add resolved-file git commit如果你在合并过程中想放弃可以git merge --abort。在变基中想放弃可以git rebase --abort。5. 查看历史与比较成为代码侦探Git仓库就是一个历史数据库学会查询是高级技能。5.1 查看提交历史git log基础的git log会按时间倒序列出提交。但它的威力在于各种参数组合git log --oneline每个提交只显示一行哈希值前7位和提交信息。git log --graph以ASCII图形显示分支合并历史。结合--oneline和--all非常强大git log --oneline --graph --all。git log -p显示每次提交的具体代码差异patch。git log --since2 weeks ago查看最近两周的提交。git log --grepbugfix搜索提交信息中包含“bugfix”的提交。git log -- file查看特定文件的修改历史。我通常将最喜欢的格式设为一个别名git config --global alias.lg “log --color --graph --prettyformat:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%an%Creset’ --abbrev-commit”5.2 比较差异git diffgit diff用于查看尚未暂存的改动工作区与暂存区的区别。git diff --staged用于查看已暂存的改动暂存区与最后一次提交的区别。更强大的用法是比较不同分支、不同提交git diff main..feature比较main分支和feature分支的最新提交差异。git diff abc123..def456比较两个特定提交之间的差异。git diff HEAD~3 HEAD比较当前提交与往前数第3个提交的差异。5.3 寻踪觅迹git blame与git bisectgit blame file逐行显示文件并标注每一行最后是谁、在哪个提交中修改的。当你想知道某段奇怪的代码是谁写的时候它非常有用。git bisect一个强大的调试工具用于二分法定位引入bug的提交。过程是git bisect start开始。git bisect bad标记当前版本有问题。git bisect good commit-hash标记一个过去已知的好版本。Git会自动切到一个中间的提交你测试这个版本是好是坏并用git bisect good或git bisect bad标记。重复步骤4Git会不断缩小范围直到定位到第一个引入问题的提交。git bisect reset结束。6. 远程协作与高级维护6.1 与远程仓库同步git fetch origin从远程仓库origin下载所有最新的分支和提交信息但不会自动合并到你当前的工作。这是一个安全的操作让你先看看别人做了什么。git pull origin main这实际上是git fetch origingit merge origin/main的快捷方式。它会拉取远程main分支的更新并合并到你的本地main分支。更推荐的方式是git pull --rebase origin main。这会在拉取更新后将你的本地提交变基到远程最新提交之上同样能保持历史线性。这需要你和团队对变基有共识。6.2 清理与维护删除分支git branch -d branch-name # 删除已合并的分支 git branch -D branch-name # 强制删除未合并的分支 git push origin --delete branch-name # 删除远程分支清理未跟踪文件git clean命令很危险但有时必要。git clean -n # 干跑显示哪些文件会被删除 git clean -f # 强制删除未跟踪的文件 git clean -fd # 强制删除未跟踪的文件和目录暂存工作现场git stash。当你临时需要切换分支但手头的工作还没完成到可以提交时用它把当前修改“藏起来”。git stash # 储藏修改 git stash list # 查看储藏列表 git stash pop # 应用最近一次储藏并删除记录 git stash apply stash{1} # 应用指定的储藏但不删除记录7. 实战场景与避坑指南理论说再多不如看几个真实场景。场景一紧急修复线上BugHotfix基于main分支创建一个热修复分支git checkout -b hotfix-critical-bug main修复bug测试提交git commit -am “修复XX空指针异常”切回main并合并git checkout main git merge --no-ff hotfix-critical-bug(--no-ff确保即使能快进也创建一个合并提交便于追踪)。打标签Tag标记版本git tag -a v1.0.1 -m “紧急修复线上空指针”推送到远程git push origin main git push origin v1.0.1将修复也合并到开发分支git checkout develop git merge main场景二误提交了大文件或敏感信息如果你不小心把node_modules目录或者配置文件里的密码提交了使用git filter-branch或更快的工具git filter-repo需要单独安装从历史中彻底删除这个文件。这是一个重写历史的行为如果提交已共享会非常麻烦。更常见的做法是如果错误发生在最近的提交用git rm --cached huge-file.log把它从Git跟踪中移除并添加到.gitignore然后git commit --amend修正上一次提交。之后推送可能需要git push --force-with-lease比--force更安全。一个关键避坑点.gitignore文件这个文件必须在一开始就设置好它告诉Git忽略哪些文件如编译产物、日志、依赖目录、IDE配置等。一个常见的坑是已经提交到仓库的文件再加入到.gitignore是无效的。你需要先将其从Git中删除git rm --cached file然后再提交。最后记住Git是一个工具这些命令是为你服务的。不要害怕尝试在一个临时仓库或分支里多练习。遇到问题时git help command是你最好的朋友它会打开详细的官方手册。当你把这些命令内化成习惯你会发现自己对代码版本的控制力达到了一个新的层次那种一切尽在掌握的感觉是图形化工具很难给予的。
