★ FEATURED ARTICLE 1. 先把Git的存储模型搞明白后面的命令全通了很多朋友学Git最痛苦的一件事是命令背了几十遍但一遇到实际情况还是不知道怎么处理。查了文档看得懂每个参数但就是不知道什么时候该用哪个。我带了几年技术团队也带过不少新人发现根子不在记性在脑子里压根没有形成Git的正确模型。1.1 不要把Git仓库想象成带撤销功能的文件夹大多数人初学Git时会下意识地把它理解成Word里的版本历史每隔一段时间存一个快照随时能倒回去。这个类比帮你在前两周内快速上手add、commit、push但也是之后所有困惑的来源。Git的存储模型更像一个小型档案室每个文件不是存了一份新版本而是每条提交记录都是一张独立的清单。这张清单上写着作者是谁、什么时候提交的、提交说明是什么、这次改了哪些文件、每个文件改动前后的内容分别对应哪一块存储区域。而且Git不是为每个文件单独存副本它会用内容寻址的方式把相同内容的数据块复用起来所以哪怕提交一万次仓库也不会膨胀到你想象的那种程度。我常用一个比方Git仓库是一栋图书馆commit不是书的再版而是一张写着哪本书从哪个位置挪到了哪个位置的流水单。流水单攒得多了你查历史时看到的不是书的旧模样而是每次搬动时发生了什么。理解这一点后面所有关于分支、合并、回滚的疑问都能解开。1.2 三个区域的流转才是Git一切操作的本质很多教程会告诉你Git有工作区、暂存区和版本库三个区域但说完就过去了没有解释为什么要有中间那个暂存区。这里我展开讲讲。工作区你电脑上肉眼可见、随手能改的文件夹。它是草稿桌乱一点没问题。暂存区一个临时存放准备提交的变更清单的盒子。它在你的.git目录里以index文件的形式存在。你git add就是把这个文件当前的内容打包一份放进盒子并更新清单里对应的条目。版本库归档柜。git commit之后暂存区里的这份清单会被永久记录成一条commit归档到objects目录里。为什么要这样设计因为真实干活时你经常会在同一次任务里改多个文件但其中可能有一两个文件只是临时调试用的你不想把它们和正式改动混在一起提交。没有暂存区的话要么只能一次提交全部改动要么就得用很笨拙的方式挑文件。有了暂存区你可以像点菜一样把想提交的菜挑进盘子剩下的继续留着。这一章要记住的最关键一点是commit记录的不是你工作区的全貌而是暂存区相对上一个commit的差异。理解了这点你就理解了为什么改了文件之后必须add才能commit为什么add之后又改文件commit捕获的只是add那一刻的内容。1.3 用一次完整提交走一遍内部流程我建议每个初学者都做一次这个实验它能帮你在心里建立非常牢固的模型。找一个空目录执行git init之后创建一个文本文件写入一行字然后依次执行git status git add . git status git commit -m first commit第一次git status你会看到文件出现在未跟踪区意思是档案室完全不知道这个东西的存在。git add之后再执行git status文件跑到了待提交区此时Git已经知道了这个文件的内容。commit之后再执行git status工作区干净了意思是当前所有内容都已经被归档。这里有个很多新手没注意过的细节执行git add之后如果你马上修改文件内容再执行git status你会看到同一个文件同时出现在待提交和未暂存两个列表里。前者是你add那一刻的内容后者是新的改动。如果不小心直接commit你新改的内容不会进去commit里存的是add时的旧内容。这个时间差是日常开发中最容易踩的暗坑之一。2. 日常最高频的六个操作配合真实场景讲透说完了模型进入实操。我不打算按文档顺序把所有命令过一遍那没有意义。我挑日常开发中真正高频使用的六个场景每个场景讲清楚为什么这样做、有没有其他做法、踩过什么坑。2.1 git clone拿到仓库只是开始git clone大概是所有Git用户第一个接触的命令但很多人clone完就直接开干忽略了两个关键信息。第一clone默认拉的是默认分支。GitHub上默认分支通常是mainGitee上可能是master如果你干活需要的是develop或者release分支clone之后第一件事应该是git branch -a看看远程有哪些分支再git checkout develop切过去。我见过太多新人直接在main上吭哧吭哧写了一周最后合并不进去的痛苦场景。第二clone时选择HTTPS还是SSH决定了你后面每次push需不需要输账号密码。SSH方式需要在本地生成密钥对把公钥配置到远端平台。生成方式很简单ssh-keygen -t ed25519 -C your_emailexample.com一路回车然后把~/.ssh/id_ed25519.pub里的内容复制到Git平台的SSH公钥设置页。这样配置一次之后所有的clone、push、pull都不再需要输入密码。实测感受是一旦用过SSH就再也回不到HTTPS了每次push输密码积累的烦躁感真的会消磨工作热情。2.2 提交前的自查三连status、diff、log现在你已经在一个分支上也改了文件准备提交了。别急着add和commit先花十秒钟做三件事。第一件git status看一下当前分支在工作区、暂存区分别有哪些变动。第二件git diff查看未暂存的具体改动内容逐行确认没有把调试代码、临时路径、密钥文件混进去。第三件git log --oneline -5看一眼最近几条commit的写法保持你这次提交的风格一致。这三个命令不一定每次都全用但至少git diff强烈建议养成习惯。我见过不止一次有人写代码时顺手把自己的绝对路径写到配置文件里或者把带密码的测试代码提交上去等到push完了才在日志里发现。提交前的十秒钟检查能让你省下后面几十分钟的补救时间。2.3 怎么才能写出别人看得懂的commit message这部分在团队协作中特别重要而且是新人和资深开发者差距最明显的地方。一个合格的commit message应该回答两个问题这次改了什么为什么这么改fix bug和update code这类消息等于什么都没说。我推荐大家用目前行业里比较通行的约定式提交风格格式大致是feat(登录模块): 增加短信验证码登录方式 - 新增send_sms_code接口用于下发验证码 - 登录接口增加sms_code参数校验逻辑 - 更新登录页前端增加验证码输入框第一行是标题feat表示新功能fix表示修bugdocs表示文档调整refactor表示重构但行为不变。括号里写影响的功能模块冒号后面用一句话概括。然后再用空行隔开写几行正文列清楚具体的改动点。这种风格的好处是未来你翻git log --oneline时能快速滤出自己想要的信息比如git log --oneline --grep^fix列出所有修bug的提交。团队用自动化工具生成changelog时也能直接从提交信息里抽取。老实说开始用这种格式后我自己的这代码当时为什么这么写的考古时间都缩短了一大截。2.4 分支操作的常见误区分支是Git的核心功能但混淆最多的也在这里。很多人会把分支想象成代码的平行宇宙这没错但如果只停留在这一层就没有理解分支的本质只是一个指针——它指向某一条commit。你创建一个新分支并没有复制任何代码只是新建了一个可以移动的指针。新指针默认指向你当前所在的commit所以你在这个新分支上改代码提交后这个指针才会往前移动到新的commit。日常开发中我建议养成每个功能一个分支的习惯。新功能开一条分支名字用feature/xxx的格式修bug的分支用fix/xxx。这样做的好处有两点一是主分支main/master永远保持可发布状态任何时候你都可以从上面拉一个新分支去做其他事不需要担心被别人的半成品干扰二是做Code Review时每个分支对应一个清晰的任务范围审查者能很轻松地对照改动。2.5 git log的三种实用姿势很多人学了git log就只会看默认输出的完整列表其实日常用得更顺的是下面几种组合。git log --oneline --graph --decorate -20这条命令只显示最近20条提交每条一行--graph会画出分支分叉和合并的线条--decorate标出分支指针和标签的位置。分支多了以后这个视图能帮你快速建立整个仓库最近的历史结构。git log -p --follow -- 某个文件名这条命令查看某个文件的完整变更历史包括每次改动的具体代码。--follow参数能让你在文件被重命名之后依然跟踪到之前的历史不然只能看到改名之后的部分。git log --author某同事 --since2 weeks ago --oneline这条用于查看某个人最近两周的提交。团队周报、代码评审准备材料时特别好用。2.6 push之前先pull但这句老话有坑刚接触Git的人一定会被叮嘱push之前先pull。这句话方向没错但如果真的只是傻傻执行git pull在某些团队里可能引发你完全没预料到的结果。原因是git pull是git fetch和git merge的复合命令先拉取远端最新提交再和你的本地分支做合并。如果两边改动了同一个文件的同一处位置你会被拉进一个合并冲突的流程里。对新手来说解决冲突是很吓人的。更稳妥的习惯是先git fetch看一眼远端发生了什么再决定用git merge还是git rebase。这两个策略的区别我在下一章详细讲。这里先记住一个纪律在push之前确认你的本地分支包含远端分支的所有提交否则push会被拒绝。不要用git push --force去绕过这个检查它是灾难的源头。3. 合并与冲突协作中最容易翻车的环节如果你是单兵作战合并和冲突可能几个月遇不上一次。但在真实项目里多人同时改同一批文件是家常便饭这一章值得每一分钟都花在上面的时间。3.1 merge和rebase两种思路两种结局假设你从主干拉了一条分支feature主干之后又有了新的提交。现在你想把主干的最新变更并入你的分支有两条路git merge把你的分支历史和主干历史并成一条交错的历史。最多会出现一个新的合并提交它有两个父提交。好处是历史完全保留坏处是图形看多了会乱。git rebase把你分支上的所有提交摘下来一条一条重新接到主干的最新提交后面。效果是你的分支历史变成一条直线看起来像主干完全没变过你的提交只是晚了一些。好处是历史干净坏处是提交的哈希值会变——如果别人已经基于你的旧提交做了工作rebase会打乱他们的基础。给个直观判断如果是你自己的功能分支还没有和别人共享rebase是首选保持提交历史线性整洁如果是公共分支或者不确定别人有没有基于你的提交工作过merge是安全选择。说实话我早期非常痴迷rebase带来的线性历史觉得那样很酷。后来吃了亏才明白所谓干净的提交历史远不如不破坏别人工作重要。现在我的原则很简单只rebase自己的分支绝不rebase公共分支。3.2 冲突到底是什么三路合并的原理冲突不是Git在惩罚你而是Git在保护你。当Git发现两个分支都修改了同一处代码它确实无法自动判断谁对谁错这时候它能做的最合理的事情就是停下请你来做决定。理解这一点能大幅减少你对冲突的心理恐惧。执行git merge产生冲突时打开那个冲突文件你会看到类似这样的标记 HEAD 这边是你当前所在分支的内容 那边是要合入的分支的内容 feature/login和之间的部分是当前分支的版本和之间是要合入分支的版本。你需要做的是把这些标记线删除保留或者重写出最终想要的代码然后保存文件再git add这个文件继续git merge --continue。冲突解决的本质其实是判断两边的代码哪一个更合理或者如何把两边的意图整合到一起。大多数时候不是简单的二选一而是需要你理解两边各自在解决什么问题再写出两者兼容的代码。3.3 解决冲突最实用的三个排查技巧第一先用git status确认有哪些文件冲突了别只看编辑器里报红的文件。有时候冲突发生在你不经意的地方比如配置文件、lock文件这些文件你几乎不可能手动合并出正确结果得重新生成。第二用可视化工具辅助。如果你用的是VS Code冲突文件会高亮显示可以直接用图形界面选择接受当前的或接受引入的或者手动编辑。我本人现在几乎不用命令行解决冲突了太费眼神。但命令行时代练出来的敏感度还在不管用什么工具解决完冲突之后一定要从头到尾读一遍最终代码很多人在可视化界面里点了接受引入的但实际上引入的版本只是某一个人的半成品组合起来逻辑根本不通。第三合并不代表完成。无论多自信冲突解决得没问题合并之后务必跑一遍测试。这听起来是废话但真的有很多冲突是因为两边各自改了同一个函数的调用约定合并后能编译、能跑但运行到某条路径就崩了。3.4 rebase冲突和merge冲突有一个关键区别如果你用的是rebase冲突的解决流程和merge大致相同但有一个细节会坑到很多人rebase时的冲突提示不会出现merge commit让你一次性解决。rebase是一条一条提交重新放所以可能在第一处就停下你解决完之后继续rebase又可能在第二处停下又得解决一次。这个过程不是bug而是rebase的内在逻辑每个提交都对应一次独立的重放你要保证每个提交放上去之后都是完整的。第一次rebase遇到冲突时我差点以为Git卡住了怎么resolve了还重复出现同样的冲突后来才理解这完全是设计如此。给新手的建议是如果你的分支上有大量提交而且和主干差异很大rebase可能让你陷入漫长的重复冲突解决中。这种场景下直接用merge往往效率更高。不要为了追求线性历史而付出不成比例的时间成本历史是给人看的代码能用才最重要。4. 写错代码、搞丢提交、提交了不该提交的文件实战救援手册再熟练的老手也免不了有手滑的时候。这一章直接讲事故处理每一个都是我在真实项目或带新人时遇到的场景背后是真实的救援经验。4.1 刚commit完就发现代码写错了怎么办场景很常见你高高兴兴提交了一个commit然后突然发现里面有个低级错误。下一个动作千万别是再改一下又提交一个而是根据错误性质选择处理方式。如果只是想修正这个commit的内容用git commit --amend。它会把你暂存区里的变动合入上一条commit而不是生成一条新的。提交后用git log --oneline看会发现commit数量没有增加只是上一条的内容变了。但注意amend是会改变提交哈希值的。如果这个commit已经push到远端并且别人可能已经拉取过amend之后你再push会被拒绝被迫使用--force这又会把别人本地基于旧提交的工作根基抽掉。所以amend只适合处理尚未push的本地commit。这个边界我用一句话给团队定过规矩本地没推过的随便改推过shared分支的绝不用amend。4.2 reset和revert一字之差一个改写历史一个不改写这是Git中非常容易混淆的一对命令我没见过谁第一次学就能完全厘清。git reset是把当前分支指针往回移动比如你连续提交了三次git reset --hard HEAD~3会把分支直接移回三次之前那三个commit在分支上就消失了。消失不等于销毁它们还在对象库里但你的正常操作已经看不到它们。git revert则完全不同它不是移动指针而是生成一条新的反向提交把指定commit的改动全部撤销然后指针照常前进。历史看起来多了一条撤销了某次改动的记录之前所有提交都原样保留。落实到使用场景场景推荐命令原因还没有push的本地提交git reset --hard直接抹掉日志干净已经push到shared分支的提交git revert不改写共享历史不会强暴队友的本地仓库只想移动指针回到旧提交git reset --soft改动保留在暂存区方便重新提交不想保留任何改动git reset --hard干净利落但别乱用--soft、--mixed、--hard的区别其实就是一个问题指针回退之后那些改动去哪--soft把改动留在暂存区--mixed默认把改动留到工作区--hard直接丢弃。日常用最多的组合是只想撤销commit但保留代码改动时用--soft想把改动打回工作区重新整理时用--mixed。4.3 reflog误操作后唯一的后悔药如果你已经用了git reset --hard把改动丢了或者不小心删了分支还有没有救有前提是你记得那串提交的哈希值或者能通过git reflog找到。git reflog记录的是你这个本地仓库里所有HEAD指针移动的历史包括reset、rebase、checkout等操作。比如你git reset --hard干掉了三个commit执行git reflog会看到之前HEAD指向过的那串哈希值。找到对应的哈希再git reset --hard 那个哈希就能把分支指针找回来。这里要强调的是reflog是本地的不会跟着push同步到远端。所以如果你在一台机器上误删了提交而另一台机器克隆过同一个仓库理论上也可以去另一台机器上找到对应的commit再拉回来。但最稳妥的做法还是重要操作前留个心眼或者干脆在push之后不随便用--hard。4.4 把大文件或密钥文件提交进Git了怎么清理这是真实工作中比较麻烦的事故之一。你写代码时为了测试把一个几十MB的二进制文件或者包含密码的.env文件add并commit了然后push上去。通常等你想起来的时候可能已经又提交了好几次。用git reset或者删除文件再提交都仅仅是让这个文件之后不再出现已经提交进历史记录的那一坨依然躺在仓库里只要有人clone就能翻出来。正确的处理分两步。第一步从当前状态移除这个文件的跟踪git rm --cached 文件名这个命令的意思是从Git跟踪中移除但保留工作区文件。这样你的本地文件还在但Git不再跟踪它。第二步如果你已经在push之后想起这事需要重写历史把该文件从所有历史提交中抹掉。最常用的工具是git filter-branch或者BFG Repo-Cleaner。我倾向于用BFG因为它的操作指令简单到夸张java -jar bfg.jar --delete-files 文件名 你的仓库路径 git reflog expire --expirenow --all git gc --prunenow --aggressive但要说清楚重写历史意味着所有后续commit的哈希都会变所有克隆过这个仓库的同事都会受影响必须提前通知协调甚至可能需要重新clone而不是pull。如果这个敏感文件已经push到了公开的远端唯一的建议是立即去远端平台把仓库设为私有或锁定并和知情者沟通。你不可能保证它已经不在任何人的电脑上了。5. 让Git真正成为日常效率工具的六个习惯最后一个部分的角度不太一样。当命令都熟练了以后真正能让Git发挥价值的其实是几个很容易被忽视的习惯。它们不会直接出现在任何一份命令速查表里但我实测下来价值很大。5.1 提交信息的原子化原则我见过很多人为了省事会把一个功能、三个bug修复、一次重构混在一个commit里提交。结果就是半个月后有人发现某个改动影响了线上行为想查清楚是哪一次提交引起的git bisect面对这种大杂烩提交基本无能为力。更好的做法是一个逻辑改动一个commit。比如你改了一个功能顺手修了个拼写错误那就分成两条commit。这不是形式主义而是让代码历史具备可回溯性。未来排查问题时你能把问题精确锁定在某个commit上而那一个commit的改动量足够小小到你能轻松审计它的全部内容。5.2 .gitignore要在项目一开始就配好很多新人会忽略.gitignore直到把node_modules、target、__pycache__这类目录提交进Git把仓库撑得很大之后才意识到问题。而这时候清理历史又是一场折腾。我的习惯是项目初始化时就把.gitignore写好不同语言的模板可以直接从GitHub的gitignore仓库里复制。然后提交之前跑一下git status确认没有不该跟踪的东西混进来。这里有个隐藏很深的坑要提一下.gitignore只对尚未被跟踪的文件生效。如果某个文件已经被add并commit了之后你再把它写进.gitignoreGit依然会继续跟踪它。这时候需要执行git rm --cached取消跟踪这个细节我在上一章事故处理里已经讲过但它值得在习惯层面再强调一次因为几乎每个人都会在这里踩一次。5.3 用alias把高频命令压缩成肌肉记忆长命令的输入成本其实比想象的高尤其是带参数的那几个。我建议把最常用的一组命令配成别名修改~/.gitconfig里对应的地方。git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm commit -m git config --global alias.lg log --oneline --graph --decorate配置完成之后git st就是git statusgit lg就能看到清爽的提交图。别小看这几个别名的节省频繁切换分支、查看状态时少敲几个字符整体的专注度差异是很明显的。配置是本地生效的不影响团队纯粹是自己用着舒服。5.4 给常用分支加上保护概念不管你用的是GitHub、GitLab还是Gitee都建议在远端平台的管理设置里把主线分支main/master启用保护规则。启用后分支不能被直接push所有合入主干的操作都必须通过Pull Request或Merge Request。这一步的意义不只是流程上的仪式感而是在机制层面防止手滑。很多代价高昂的事故都起源于某个人直接在主干上提交了一个未经验证的版本。保护分支之后每次合入都有一次环节让同事看到改动这条保护值得你用两分钟去配置换来以后每月的安心。5.5 善用git stash处理还没做完就要切换分支的尴尬场景很常见你正在feature/A上改代码改到一半测试同学告诉你线上有个紧急bug得马上修得切到hotfix分支。如果直接git checkoutGit会因为工作区有未提交的改动而拒绝切换。有两个选择。一个是硬着头皮先提交再切过去但你会往分支历史里塞一条半成品commit另一个是git stash把当前改动先收起来工作区恢复干净切走修复完线上bug之后切回来再git stash pop恢复之前改动。更讲究一点stash时可以用git stash save 描述信息这样多个stash之间你能分辨谁是谁。注意stash是本地保存的不跟着远端走所以如果机器坏了stash里的工作也没了重要工作别只会stash该提交的还是要提交。5.6 IDE与命令行并不是二选一我知道有些老开发者对IDE里的Git可视化界面嗤之以鼻但我个人认为工具没有高下之分熟手用什么顺手就都是好工具。IDEA和VS Code集成的Git功能已经很强了图形化diff、图形化解决冲突、图形化分支管理对效率的提升是实实在在的。我自己现在的工作流是混合的常规提交会用命令行加别名快速完成但解决复杂冲突、查看历史图时一定打开IDE的可视化界面。关键不在于哪个更正统而在于哪个能让你把大脑用来思考代码逻辑而不是浪费在记命令参数上。尝试找到你自己的混合节奏。最后分享一个我用了很久的小习惯每次要push之前跑一次git log --oneline main..当前分支名看看当前分支相比主干多了哪些commit。这个动作两秒钟就能完成却总能提醒我是不是有些调试用的临时提交混进来了。Git是个很宽容的工具绝大多数错误都有挽回办法但这不代表我们应该故意制造挽回路。把它当做一个固定的日常动作远比你练熟一百条救援命令更有用。
阅读完成 · 觉得有帮助？
