Git 这东西刚入行那会儿我也觉得它玄乎。不就是保存文件吗我复制一份改个名不就行了直到有一次改崩了一个功能想退回昨天的版本结果发现文件夹里躺着最终版最终版2真最终版打死也不改了版——那一刻我才明白靠手动复制管理版本迟早要出事。Git 就是来解决这个问题的它帮你把每一次改动都记下来随时能翻旧账、随时能开新路、随时能跟别人合着干。这篇文章不堆术语我按一个零基础的人从完全不懂到能上手干活的路径来讲把安装、配置、仓库、分支、合并、协作这些事一件件说清楚顺带把新手最容易踩的坑提前给你标出来。看完你至少能做到自己建仓库、提交代码、开分支、合并分支、推到远程、跟同事协作不打架。1. 先把 Git 到底解决什么问题讲透1.1 没有版本控制的日子是什么样的我先描述一个场景你看看熟不熟悉。你写一个文档或者一段代码改到一半觉得不对劲想回到上午十点的状态。这时候你有两个选择一是凭记忆手动改回去二是提前复制过一份。大多数人靠的是第二种于是文件夹里就出现了这种命名方案.docx、方案_改.docx、方案_最终.docx、方案_最终_真的最终.docx、方案_最终_老板改过.docx。这种土办法有三个致命问题。第一你根本记不住每个文件到底改了啥时间一长自己都分不清哪个是哪个。第二多人协作时彻底乱套你把文件发给我我改完发回给你你手上那份和我手上那份就不一样了谁覆盖谁全靠运气。第三出了问题没法追溯你只知道昨天还好好的但昨天到底动了哪一行完全查不到。Git 的出现就是为了干掉这三个问题。它做的事情本质上一句话给项目的每一次变化拍一张快照并且记录下是谁、什么时候、为什么拍的这张快照。有了这些快照你就能在任意两个时间点之间来回跳也能清楚地看到每次改动具体动了哪些内容。1.2 Git 和网盘复制粘贴的本质区别很多人第一次接触 Git 会问这不就是个网盘吗我把代码传上去不就行了这个理解差得比较远我用一个类比说清楚。网盘存的是文件的结果它只知道你上传了一个叫 a.txt 的文件。Git 存的是文件的演变过程它知道a.txt 在第 1 版有 3 行第 2 版你加了 2 行删了 1 行第 3 版你把第 2 行改了。这个区别带来的直接好处是网盘只能给你最新版Git 能给你任意一版还能告诉你每一版之间差在哪。再打个比方。复制粘贴管理版本就像你每次改稿都重新打印一份纸质稿堆在桌上改到第十版桌上堆了十份纸你想找第三版里的一句话得一张张翻。Git 更像是一个带时间轴的编辑器你拖动时间轴就能看到任意时刻的完整内容还能高亮显示每次改动的部分。还有一个关键区别是分支。这个后面会详细讲你先记住一句话Git 允许你在不影响主线的情况下另开一条线去试新想法试成了就合回来试砸了直接扔掉主线毫发无伤。这是复制粘贴永远做不到的。1.3 谁需要学 Git学到什么程度够用不是所有人都需要把 Git 学成专家。我按使用场景分三档你对号入座。第一档个人开发者或者独立写作者。你只需要掌握安装配置、建仓库、提交、看历史、回退。这几个命令学会了你一个人干活就够用了能彻底告别最终版2。第二档团队协作中的普通成员。在上一档基础上你还要会拉取远程代码、推送自己的改动、开分支、合并分支、解决冲突。这是绝大多数公司里程序员、文档写作者、设计稿管理者的日常需求。第三档团队里的 Git 负责人或者 DevOps。你需要懂分支策略设计、代码评审流程、标签发布、钩子脚本、仓库迁移。这一档涉及团队规范不是本文重点但我会在协作那部分点到。对绝大多数人来说第二档就是天花板了把第二档的内容吃透你在团队里就不会因为 Git 掉链子。下面我就按这个路径带你走一遍。2. 安装和第一次配置别在这一步就埋雷2.1 各平台安装方式的选择逻辑安装本身不难但选错方式会给后面添麻烦我说说我的选择逻辑。Windows 上最省心的是去官网下载安装包一路下一步。安装过程中有一个选项叫Adjusting your PATH environment默认选的是Git from the command line and also from 3rd-party software这个保持默认就行它会把 Git 加到系统环境变量里这样你在任意命令行窗口都能用git命令。另一个选项是换行符处理默认Checkout Windows-style, commit Unix-style line endings就可以这个设置能避免 Windows 和 Linux 协作时的换行符冲突。macOS 上如果你装了 Xcode 命令行工具Git 通常已经自带了终端里敲git --version能出版本号就说明有。想装新版本可以用 Homebrew一条命令搞定。我个人的习惯是能用系统自带就用自带的除非版本太老影响功能。Linux 上直接用包管理器Debian 系用aptRedHat 系用yum或dnf这个不用多说。提示安装完成后一定要在终端里敲一次git --version确认能出版本号。我见过不少人装完了但环境变量没配好敲 git 提示不是内部或外部命令白折腾半天。2.2 那三行必须配置的命令以及为什么必须配装完之后第一件事不是急着建仓库而是配置身份。Git 每次提交都会记录是谁提交的这个信息就来自你的配置。命令是这两条git config --global user.name 你的名字 git config --global user.email 你的邮箱--global表示这是全局配置对你这台机器上所有仓库生效。为什么必须配因为如果你不配第一次提交时 Git 会报错或者用一堆默认值导致提交记录里作者信息是乱的。团队协作时别人看到你的提交不知道是谁干的追责和沟通都成问题。第三条建议配的是默认分支名git config --global init.defaultBranch main老版本的 Git 默认分支叫master新版本逐渐转向main。你提前设好新建仓库时就不会因为分支名不一致跟团队对不上。这个不是必须但能省掉后面改名的麻烦。配置完可以用git config --list查看所有配置确认写进去了。这里有个新手常问的问题邮箱能不能随便填技术上可以但强烈建议填你真实在用的邮箱因为很多代码托管平台靠邮箱来关联你的提交和账号填错了你的贡献记录就挂到别人名下了。2.3 配置错了怎么改以及配置存在哪配置写错了不用慌重新执行一遍同样的命令就会覆盖。比如名字写错了再跑一次git config --global user.name 正确的名字就行。这些配置存在哪全局配置存在你用户目录下的.gitconfig文件里Windows 一般在C:\Users\你的用户名\.gitconfigmacOS 和 Linux 在~/.gitconfig。你可以直接用文本编辑器打开看内容就是一堆键值对。除了全局配置还有仓库级配置。你在某个仓库目录里执行不带--global的git config改的就是这个仓库的配置存在仓库的.git/config文件里。仓库级配置优先级高于全局配置这个机制在需要给某个项目单独设邮箱时很有用。注意如果你在公司电脑上配了个人邮箱提交到公司仓库时作者信息就是个人的有些公司对此有规范要求。反过来也一样。所以换项目时留意一下当前生效的是哪套配置用git config user.email可以查看当前仓库实际生效的值。3. 仓库、提交、历史Git 的日常三件事3.1 仓库到底是什么本地仓库和远程仓库的关系仓库这个词听着唬人其实就是一个被 Git 管理的文件夹。你在一个文件夹里执行git init这个文件夹就变成了一个 Git 仓库Git 会在里面建一个隐藏的.git目录所有版本信息都存在这里。这里要分清两个概念本地仓库和远程仓库。本地仓库就是你电脑上这个文件夹你所有的提交操作默认都是先提交到本地。远程仓库是放在服务器上的仓库比如公司内网的 GitLab、或者公网的代码托管平台。本地和远程之间通过推送和拉取来同步。为什么要分本地和远程因为这样你可以在没网的时候照样提交等有网了再一次性推上去。这个设计对经常在飞机上、地铁里干活的人特别友好。而且本地提交速度快不依赖网络体验比每次保存都往服务器传要好得多。一个容易混淆的点git init建的仓库和从远程克隆下来的仓库本质上是一样的区别只是克隆下来的仓库已经跟远程建立了关联而 init 建的仓库需要你手动关联远程地址。3.2 提交的完整流程工作区、暂存区、版本库这是 Git 最核心也最容易让新手懵的地方。Git 把文件的状态分成三个区域我一个个说。工作区就是你眼睛能看到的文件夹你在这里改文件。暂存区是一个中间地带你改完的文件要先放到这里。版本库就是.git目录提交之后内容才真正存进版本库。为什么要有暂存区这个中间层直接提交不行吗可以但暂存区给了你一个挑选的机会。比如你今天改了三个文件其中两个是修 bug一个是顺手改的格式。你可以只把修 bug 的两个文件放进暂存区提交格式改动单独再提交一次。这样每次提交都对应一件完整的事历史记录清晰将来回退也精准。完整流程是这样的git status # 看当前有哪些改动 git add 文件名 # 把指定文件放进暂存区 git add . # 把所有改动放进暂存区 git commit -m 说明 # 把暂存区的内容提交到版本库git status是你最该养成的习惯改完东西先看一眼状态它会用红字标出没暂存的改动绿字标出已暂存的改动。新手经常犯的错是git add完忘了commit以为已经保存了其实只是放进了暂存区。3.3 提交信息怎么写才算合格-m后面那句话不是随便写的它是给未来的你看的。我见过太多提交信息写修改更新fix的过一个月自己都不知道改了啥。我的写法习惯是第一行用一句话说清楚这次提交干了什么控制在 50 字以内如果一句话说不完空一行再写详细说明。比如修复登录页在 Safari 下按钮错位的问题 原因是 flex 布局在旧版 Safari 下需要加 -webkit- 前缀 给按钮容器补上后测试通过。这样写的好处是git log一眼扫过去能看懂每次提交的主题需要细节时再看正文。团队协作时别人 review 你的代码也能快速理解你的意图。还有一个实用技巧提交信息里可以写关联的工单号比如修复登录超时问题 #1234很多平台会自动把提交和工单关联起来追溯起来非常方便。3.4 查看历史log 的几种常用姿势git log是查看提交历史的命令但默认输出信息量太大新手容易看花眼。我推荐几个常用参数。git log --oneline # 每个提交压成一行最常用 git log --oneline --graph # 加上分支合并的图形化展示 git log -5 # 只看最近 5 条 git log --author名字 # 只看某人的提交 git log 文件名 # 只看某个文件的改动历史--oneline是我用得最多的输出像这样a1b2c3d 修复登录页按钮错位 e4f5g6h 新增用户头像上传功能 i7j8k9l 初始化项目前面那串字符是提交的身份证号叫 commit hash后面回退的时候要用到。--graph在分支多的时候特别有用它用字符画出分支的分叉和合并一眼就能看出项目是怎么演进的。提示如果git log输出太长卡在了一个冒号提示符那里按q就能退出。这是分页器在起作用不是卡死了新手经常在这里慌。4. 分支Git 最值钱的功能也是最容易用错的功能4.1 分支的本质一个可以移动的指针很多人觉得分支很神秘其实它的本质简单到离谱分支就是一个指向某次提交的指针。你建一个分支就是新建一个指针指向当前提交你在分支上提交指针就往前移动一格。理解这一点很多操作就顺了。比如切换分支其实就是把 HEAD当前所在位置的标记指向另一个指针合并分支就是把两个指针指向的历史合到一起。为什么这个设计厉害因为它意味着建分支的成本极低。在 Git 里建一个分支几乎是瞬间完成的不复制任何文件只是写一个 41 字节的指针。所以 Git 鼓励你多开分支想试什么新东西就开一个试完不满意直接删主线完全不受影响。对比一下老式的版本控制工具建分支要复制整个项目目录慢且占空间所以那时候大家都不敢随便开分支。Git 把这个成本降到接近零工作方式就彻底变了。4.2 分支的日常操作建、切、看、删常用命令就这几个git branch # 列出所有本地分支当前分支前面有星号 git branch 新分支名 # 基于当前提交建一个新分支 git checkout 分支名 # 切换到指定分支 git checkout -b 新分支名 # 建一个新分支并立刻切过去最常用 git branch -d 分支名 # 删除已合并的分支 git branch -D 分支名 # 强制删除未合并的分支git checkout -b这个组合命令是我用得最多的建分支和切换一步到位。新版本 Git 还提供了git switch命令专门用来切分支语义更清晰git switch 分支名 git switch -c 新分支名checkout和switch功能上有重叠switch是后来加的专门管分支切换避免checkout一个命令干太多事造成混淆。你用哪个都行团队里统一就好。删除分支时要注意-d只能删已经合并的分支如果分支上有没合并的提交Git 会拦着你不让删这是保护机制。确实想删就用-D但删之前想清楚那些提交可能就找不回来了其实还能通过 reflog 找回但那是进阶话题。4.3 分支命名和分支策略的实战建议分支名怎么起团队最好有个约定。我见过比较清晰的几种命名方式功能分支feature/用户登录或feature/login修复分支fix/登录超时或bugfix/login-timeout发布分支release/1.2.0紧急修复hotfix/支付崩溃用斜杠分层的好处是git branch列出来时同类分支会排在一起一目了然。纯中文分支名技术上没问题但有些平台或工具对中文支持不好我一般建议用英文加短横线。分支策略上小团队最简单的是主干开发加功能分支main分支始终保持可发布状态任何人做新功能都从main切一个功能分支出去做完合并回来。大一点的团队可能会用develop作为集成分支main只放正式发布版本功能分支先合到develop测试通过再合到main。注意不管用哪种策略有一条铁律——不要在 main 分支上直接改代码。main 是大家的公共财产直接在上面改容易把别人的工作搞乱。养成干活先切分支的习惯能避免 90% 的协作事故。4.4 合并分支的两种方式merge 和 rebase把分支合回来有两种方式这是新手最容易搞混的地方我重点讲。merge的做法是把两个分支的历史合到一起如果两边都有新提交Git 会自动生成一个合并提交来记录这次合并。历史会呈现分叉再汇合的形状。rebase的做法是把你分支上的提交一个个摘下来重新接到目标分支的最新提交后面。历史会变成一条直线看起来像你一直在目标分支上顺序开发一样。用哪个我的经验是场景推荐方式原因功能分支合并回主干merge保留分支存在的痕迹历史真实本地分支同步主干最新代码rebase让本地历史保持整洁避免无意义的合并提交已经推送到远程的公共分支绝对不要 rebase会改写历史导致别人拉取时冲突个人本地整理提交rebase可以合并琐碎提交让历史更清晰rebase 有个大坑它会改写提交的 hash。如果你 rebase 了一个已经推送到远程、别人也在用的分支别人再拉取时历史就对不上了会引发一堆冲突。所以记住一句话只 rebase 自己本地、还没推送的提交。5. 远程协作从单机玩家到团队作战5.1 关联远程仓库和第一次推送本地仓库建好后要跟远程仓库建立联系命令是git remote add origin 远程仓库地址 git remote -v # 查看已关联的远程 git push -u origin main # 第一次推送-u 记住关联关系origin是远程仓库的默认别名你可以改成别的名字但大家都用 origin没必要标新立异。-u参数的作用是把本地 main 分支和远程 main 分支关联起来之后你在这个分支上直接敲git push和git pull就行不用再指定远程和分支名。远程仓库地址有两种协议HTTPS 和 SSH。HTTPS 用起来简单但每次推送要输账号密码现在多数平台用令牌代替密码。SSH 需要先配置密钥配好之后免密推送一劳永逸。团队内部一般推荐 SSH配置一次省心很久。5.2 拉取、推送、冲突协作的日常循环团队协作的日常循环基本是这样的git pull # 先把远程最新代码拉下来 # 干活改文件 git add . git commit -m 说明 git push # 推上去看起来简单但git pull这一步经常出问题。git pull实际上是两个动作的合体先git fetch把远程最新内容下载到本地再git merge合并到你当前分支。如果远程和本地都改了同一个文件的同一部分合并时就会冲突。冲突长什么样Git 会在文件里插入这样的标记 HEAD 你本地的内容 远程的内容 远程分支你需要手动决定保留哪部分把标记删掉改成最终想要的样子然后git add这个文件再git commit完成合并。这个过程第一次遇到会慌其实就是在问你这两段你想留哪个你手动编辑成想要的结果就行。提示解决冲突时不要怕Git 不会自动帮你选它把决定权交给你。改完之后一定要跑一遍测试确认合并结果是对的因为冲突解决错了很容易引入 bug。5.3 减少冲突的实操习惯冲突虽然能解决但解决起来费时费力最好的办法是少产生冲突。我总结几个习惯第一勤拉取。每天开工前先git pull别等攒了一周才拉那时候冲突会多到你想哭。第二小步提交、小步推送。一个功能拆成几次提交做完一小块就推一次别憋一个大招。改动越小跟别人冲突的概率越低。第三别动别人的文件。如果你发现要改的文件别人也在改先沟通一下看能不能分工或者错开时间。第四功能分支生命周期要短。一个功能分支从建到合并最好控制在几天内拖得越久跟主干偏离越大合并时冲突越多。第五合并前先同步主干。在功能分支上先git merge main或者git rebase main把主干最新改动合进来在本地解决完冲突再推这样主干上的合并就干净了。5.4 代码评审和合并请求的基本流程团队协作里功能分支做完不是直接合到主干而是先发一个合并请求不同平台叫法不同有的叫 Pull Request有的叫 Merge Request让同事 review 一下。这个流程的价值在于多一双眼睛看代码能提前发现 bug、风格问题、安全隐患。review 的人可以在具体某一行上留评论作者根据评论修改改完再推评论会自动关联到新的提交上。作为作者发合并请求时写清楚这几件事这个改动解决了什么问题、怎么实现的、测试情况如何、有没有需要特别注意的地方。作为 reviewer重点看逻辑对不对、边界情况处理了没、有没有明显的性能问题、命名和风格是否符合团队规范。这个流程刚开始会觉得麻烦但它是团队代码质量的重要保障。我待过的团队里坚持做 review 的线上事故明显少。6. 新手最容易踩的坑和救命命令6.1 提交错了、提交多了、提交漏了怎么办提交信息写错了用git commit --amend -m 新的提交信息这个命令会修改最近一次提交的信息。如果只是想补充几个文件到最近一次提交里先git add那些文件再git commit --amend --no-edit--no-edit表示不改提交信息。提交漏了文件同样用git add加上git commit --amend --no-edit。想撤销最近一次提交但保留改动用git reset --soft HEAD~1这会把最近一次提交撤掉但改动还在暂存区你可以重新组织再提交。如果把--soft换成--mixed默认改动会回到工作区但不在暂存区换成--hard改动直接丢弃这个要慎用。注意--amend和reset都会改写历史如果那次提交已经推送到远程改完再推需要强制推送而强制推送会影响别人。所以这些操作尽量在推送之前做。6.2 改崩了想回到某个历史版本如果只是想让某个文件回到历史版本用git checkout 提交号 -- 文件名如果想让整个项目回到某个历史提交的状态用git reset --hard 提交号但--hard会丢弃之后的所有改动用之前想清楚。更安全的做法是新建一个分支指向那个历史提交先看看再说git checkout -b 临时分支 提交号这样你可以在临时分支上检查历史状态确认没问题再决定怎么处理主线不受影响。还有一个救命命令是git reflog它记录了 HEAD 的所有移动历史包括那些你以为已经丢失的提交。如果你不小心reset --hard删掉了东西用git reflog找到那个提交号再git reset --hard 提交号就能找回来。这个命令救过我好几次强烈建议记住。6.3 那些让人一脸懵的报错和应对新手最常遇到的几个报错我列出来Your local changes would be overwritten by merge你想切换分支或拉取但本地有未提交的改动会冲突。解决办法是先提交或暂存git stash本地改动再操作。fatal: refusing to merge unrelated histories两个仓库的历史没有共同祖先常见于把两个独立初始化的仓库合并。加--allow-unrelated-histories参数可以强制合并但要想清楚是不是真的需要。Permission denied (publickey)SSH 密钥没配好或者没加到平台账号里。检查密钥是否生成、是否添加到平台的 SSH 设置里。Updates were rejected because the remote contains work that you do not have远程有你本地没有的提交直接推会被拒。先git pull把远程内容拉下来合并再推。detached HEAD你 checkout 到了一个具体的提交号而不是分支名处于游离状态。这时候的提交不属于任何分支容易丢。想保留就git switch -c 新分支名建个分支接住。6.4 暂存和忽略两个提升效率的小工具git stash用来临时保存未提交的改动让你能干净地切换分支。比如你改到一半突然要去修个紧急 bug又不想把半成品提交就可以git stash # 把当前改动存起来 # 切分支修 bug git stash pop # 回来把改动恢复出来.gitignore文件用来告诉 Git 哪些文件不要管比如编译产物、日志、本地配置、依赖目录。这个文件很重要如果不配你会把一堆没用的文件提交进去仓库越来越臃肿。常见的忽略内容node_modules/ *.log .env dist/ .idea/提示.gitignore只对还没被跟踪的文件生效。如果一个文件已经被提交过再加到.gitignore里是不起作用的需要先用git rm --cached 文件名把它从跟踪列表里移除。7. 从会用到用顺的几个进阶习惯7.1 图形化工具和命令行的取舍命令行是 Git 的原生形态功能最全但有些操作确实不如图形界面直观比如看分支图、逐行暂存、解决复杂冲突。我的建议是日常提交、拉取、推送用命令行看历史和解决冲突可以借助图形工具。常见的图形工具有 Git 自带的gitk、跨平台的 Sourcetree、以及各种编辑器内置的 Git 面板。编辑器内置的 Git 功能现在做得很好改动的文件、逐行 diff、暂存、提交都能在编辑器里完成不用来回切窗口。但我不建议新手一上来就全靠图形工具因为图形工具会隐藏很多细节出了问题你不知道底层发生了什么。先用命令行把基本概念和流程走通再用图形工具提效这个顺序比较合理。7.2 提交粒度为什么一次提交只做一件事这个习惯我反复强调因为它对历史可读性影响巨大。一次提交只做一件事意味着修 bug 的提交里不要夹带格式调整加功能的提交里不要顺手重构无关代码。好处有三个。第一回退精准某个提交出问题直接 revert 那一个就行不会误伤别的改动。第二review 容易reviewer 一眼能看懂这次提交的意图。第三排查问题快用git log和git blame定位问题时每个提交的边界清晰。怎么做到靠暂存区。改完一堆东西后用git add只挑相关的文件或代码块放进暂存区分多次提交。编辑器里通常支持逐块暂存可以把一个文件里的不同改动分开提交非常实用。7.3 标签给重要版本打个记号标签tag用来给某个提交起一个固定的名字通常用于标记发布版本。比如git tag v1.0.0 git tag -a v1.0.0 -m 第一个正式版本 # 带说明的标签 git push origin v1.0.0 # 推送标签到远程标签和分支的区别是分支会移动标签不会。你给 v1.0.0 打了标签它就永远指向那个提交不管后面分支怎么走。发布版本、里程碑节点用标签标记将来想找回某个版本直接 checkout 标签就行比记提交号方便得多。7.4 保持仓库健康的日常维护仓库用久了会有些小问题定期做几件事能保持健康。git gc会清理仓库里的垃圾对象压缩存储仓库大的时候能明显减小体积。一般不用手动跑Git 会自动触发但仓库特别大时可以手动执行一次。git fsck用来检查仓库完整性偶尔跑一下能提前发现损坏的对象。定期清理已经合并的本地分支用git branch --merged列出已合并的分支确认后批量删除。远程分支也可以清理git remote prune origin会删掉远程已经不存在但本地还留着的分支引用。还有一点别把大文件提交进仓库。二进制文件、视频、数据集这类东西一旦提交会永久留在历史里仓库体积会爆炸。这类文件应该用专门的大文件存储方案或者干脆放在仓库外面。8. 我这些年用 Git 攒下的实在经验8.1 关于学习路径的一点真心话Git 的命令很多但真正常用的就那么十几个。新手不要试图把所有命令背下来那样既痛苦又记不住。正确的做法是先把提交、拉取、推送、分支、合并这五个动作练熟能独立完成一个完整的协作循环然后再按需学其他命令。遇到问题先查git status和git log这两个命令能告诉你当前处于什么状态、历史发生了什么大部分困惑看一眼就清楚了。实在搞不定git reflog是最后的救命稻草它记录了一切。我见过太多人因为怕把仓库搞坏而不敢操作结果一直停留在只会提交的阶段。其实 Git 的容错性比想象中强只要提交过的东西基本都能找回来。大胆用出问题再查这是学 Git 最快的方式。8.2 团队协作里那些不成文的规矩技术之外团队协作有些软性的规矩我分享几条。提交信息用团队统一的语言和格式别一个人写中文一个人写英文混在一起看着乱。分支命名也统一别有人用feature/xxx有人用dev-xxx。合并别人的分支前先看一眼对方的改动别闭着眼睛合。合并请求里该写的说明写清楚别让 reviewer 猜你的意图。遇到冲突拿不准怎么解决找改动那部分代码的同事一起看别自己瞎猜着合。合错了引入的 bug 往往很隐蔽排查起来更费劲。还有别在公共分支上强制推送。强制推送会改写历史别人本地的记录就跟远程对不上了轻则冲突重则丢代码。这个规矩在团队里基本是红线。8.3 遇到搞不定的情况先备份再折腾最后分享一个保命习惯在尝试不确定的操作之前先给当前状态留个后路。最简单的做法是建一个临时分支指向当前提交git branch backup-20240101这样不管后面怎么折腾你都能通过git checkout backup-20240101回到折腾前的状态。等确认新操作没问题了再把这个临时分支删掉。这个习惯看起来多余但真到了关键时刻能救命。我有一次在整理历史时手滑差点丢掉一整天的提交就是靠之前随手建的备份分支找回来的。花几秒钟建个备份换的是折腾时的底气这笔账怎么算都划算。Git 这东西说到底就是个工具它的价值在于让你敢改、能退、好协作。把上面这些走一遍你就能从怕用 Git变成离不开 Git。剩下的就是在实际项目里多用用着用着就顺了。
Git 这东西刚入行那会儿我也觉得它玄乎。不就是保存文件吗我复制一份改个名不就行了直到有一次改崩了一个功能想退回昨天的版本结果发现文件夹里躺着最终版最终版2真最终版打死也不改了版——那一刻我才明白靠手动复制管理版本迟早要出事。Git 就是来解决这个问题的它帮你把每一次改动都记下来随时能翻旧账、随时能开新路、随时能跟别人合着干。这篇文章不堆术语我按一个零基础的人从完全不懂到能上手干活的路径来讲把安装、配置、仓库、分支、合并、协作这些事一件件说清楚顺带把新手最容易踩的坑提前给你标出来。看完你至少能做到自己建仓库、提交代码、开分支、合并分支、推到远程、跟同事协作不打架。1. 先把 Git 到底解决什么问题讲透1.1 没有版本控制的日子是什么样的我先描述一个场景你看看熟不熟悉。你写一个文档或者一段代码改到一半觉得不对劲想回到上午十点的状态。这时候你有两个选择一是凭记忆手动改回去二是提前复制过一份。大多数人靠的是第二种于是文件夹里就出现了这种命名方案.docx、方案_改.docx、方案_最终.docx、方案_最终_真的最终.docx、方案_最终_老板改过.docx。这种土办法有三个致命问题。第一你根本记不住每个文件到底改了啥时间一长自己都分不清哪个是哪个。第二多人协作时彻底乱套你把文件发给我我改完发回给你你手上那份和我手上那份就不一样了谁覆盖谁全靠运气。第三出了问题没法追溯你只知道昨天还好好的但昨天到底动了哪一行完全查不到。Git 的出现就是为了干掉这三个问题。它做的事情本质上一句话给项目的每一次变化拍一张快照并且记录下是谁、什么时候、为什么拍的这张快照。有了这些快照你就能在任意两个时间点之间来回跳也能清楚地看到每次改动具体动了哪些内容。1.2 Git 和网盘复制粘贴的本质区别很多人第一次接触 Git 会问这不就是个网盘吗我把代码传上去不就行了这个理解差得比较远我用一个类比说清楚。网盘存的是文件的结果它只知道你上传了一个叫 a.txt 的文件。Git 存的是文件的演变过程它知道a.txt 在第 1 版有 3 行第 2 版你加了 2 行删了 1 行第 3 版你把第 2 行改了。这个区别带来的直接好处是网盘只能给你最新版Git 能给你任意一版还能告诉你每一版之间差在哪。再打个比方。复制粘贴管理版本就像你每次改稿都重新打印一份纸质稿堆在桌上改到第十版桌上堆了十份纸你想找第三版里的一句话得一张张翻。Git 更像是一个带时间轴的编辑器你拖动时间轴就能看到任意时刻的完整内容还能高亮显示每次改动的部分。还有一个关键区别是分支。这个后面会详细讲你先记住一句话Git 允许你在不影响主线的情况下另开一条线去试新想法试成了就合回来试砸了直接扔掉主线毫发无伤。这是复制粘贴永远做不到的。1.3 谁需要学 Git学到什么程度够用不是所有人都需要把 Git 学成专家。我按使用场景分三档你对号入座。第一档个人开发者或者独立写作者。你只需要掌握安装配置、建仓库、提交、看历史、回退。这几个命令学会了你一个人干活就够用了能彻底告别最终版2。第二档团队协作中的普通成员。在上一档基础上你还要会拉取远程代码、推送自己的改动、开分支、合并分支、解决冲突。这是绝大多数公司里程序员、文档写作者、设计稿管理者的日常需求。第三档团队里的 Git 负责人或者 DevOps。你需要懂分支策略设计、代码评审流程、标签发布、钩子脚本、仓库迁移。这一档涉及团队规范不是本文重点但我会在协作那部分点到。对绝大多数人来说第二档就是天花板了把第二档的内容吃透你在团队里就不会因为 Git 掉链子。下面我就按这个路径带你走一遍。2. 安装和第一次配置别在这一步就埋雷2.1 各平台安装方式的选择逻辑安装本身不难但选错方式会给后面添麻烦我说说我的选择逻辑。Windows 上最省心的是去官网下载安装包一路下一步。安装过程中有一个选项叫Adjusting your PATH environment默认选的是Git from the command line and also from 3rd-party software这个保持默认就行它会把 Git 加到系统环境变量里这样你在任意命令行窗口都能用git命令。另一个选项是换行符处理默认Checkout Windows-style, commit Unix-style line endings就可以这个设置能避免 Windows 和 Linux 协作时的换行符冲突。macOS 上如果你装了 Xcode 命令行工具Git 通常已经自带了终端里敲git --version能出版本号就说明有。想装新版本可以用 Homebrew一条命令搞定。我个人的习惯是能用系统自带就用自带的除非版本太老影响功能。Linux 上直接用包管理器Debian 系用aptRedHat 系用yum或dnf这个不用多说。提示安装完成后一定要在终端里敲一次git --version确认能出版本号。我见过不少人装完了但环境变量没配好敲 git 提示不是内部或外部命令白折腾半天。2.2 那三行必须配置的命令以及为什么必须配装完之后第一件事不是急着建仓库而是配置身份。Git 每次提交都会记录是谁提交的这个信息就来自你的配置。命令是这两条git config --global user.name 你的名字 git config --global user.email 你的邮箱--global表示这是全局配置对你这台机器上所有仓库生效。为什么必须配因为如果你不配第一次提交时 Git 会报错或者用一堆默认值导致提交记录里作者信息是乱的。团队协作时别人看到你的提交不知道是谁干的追责和沟通都成问题。第三条建议配的是默认分支名git config --global init.defaultBranch main老版本的 Git 默认分支叫master新版本逐渐转向main。你提前设好新建仓库时就不会因为分支名不一致跟团队对不上。这个不是必须但能省掉后面改名的麻烦。配置完可以用git config --list查看所有配置确认写进去了。这里有个新手常问的问题邮箱能不能随便填技术上可以但强烈建议填你真实在用的邮箱因为很多代码托管平台靠邮箱来关联你的提交和账号填错了你的贡献记录就挂到别人名下了。2.3 配置错了怎么改以及配置存在哪配置写错了不用慌重新执行一遍同样的命令就会覆盖。比如名字写错了再跑一次git config --global user.name 正确的名字就行。这些配置存在哪全局配置存在你用户目录下的.gitconfig文件里Windows 一般在C:\Users\你的用户名\.gitconfigmacOS 和 Linux 在~/.gitconfig。你可以直接用文本编辑器打开看内容就是一堆键值对。除了全局配置还有仓库级配置。你在某个仓库目录里执行不带--global的git config改的就是这个仓库的配置存在仓库的.git/config文件里。仓库级配置优先级高于全局配置这个机制在需要给某个项目单独设邮箱时很有用。注意如果你在公司电脑上配了个人邮箱提交到公司仓库时作者信息就是个人的有些公司对此有规范要求。反过来也一样。所以换项目时留意一下当前生效的是哪套配置用git config user.email可以查看当前仓库实际生效的值。3. 仓库、提交、历史Git 的日常三件事3.1 仓库到底是什么本地仓库和远程仓库的关系仓库这个词听着唬人其实就是一个被 Git 管理的文件夹。你在一个文件夹里执行git init这个文件夹就变成了一个 Git 仓库Git 会在里面建一个隐藏的.git目录所有版本信息都存在这里。这里要分清两个概念本地仓库和远程仓库。本地仓库就是你电脑上这个文件夹你所有的提交操作默认都是先提交到本地。远程仓库是放在服务器上的仓库比如公司内网的 GitLab、或者公网的代码托管平台。本地和远程之间通过推送和拉取来同步。为什么要分本地和远程因为这样你可以在没网的时候照样提交等有网了再一次性推上去。这个设计对经常在飞机上、地铁里干活的人特别友好。而且本地提交速度快不依赖网络体验比每次保存都往服务器传要好得多。一个容易混淆的点git init建的仓库和从远程克隆下来的仓库本质上是一样的区别只是克隆下来的仓库已经跟远程建立了关联而 init 建的仓库需要你手动关联远程地址。3.2 提交的完整流程工作区、暂存区、版本库这是 Git 最核心也最容易让新手懵的地方。Git 把文件的状态分成三个区域我一个个说。工作区就是你眼睛能看到的文件夹你在这里改文件。暂存区是一个中间地带你改完的文件要先放到这里。版本库就是.git目录提交之后内容才真正存进版本库。为什么要有暂存区这个中间层直接提交不行吗可以但暂存区给了你一个挑选的机会。比如你今天改了三个文件其中两个是修 bug一个是顺手改的格式。你可以只把修 bug 的两个文件放进暂存区提交格式改动单独再提交一次。这样每次提交都对应一件完整的事历史记录清晰将来回退也精准。完整流程是这样的git status # 看当前有哪些改动 git add 文件名 # 把指定文件放进暂存区 git add . # 把所有改动放进暂存区 git commit -m 说明 # 把暂存区的内容提交到版本库git status是你最该养成的习惯改完东西先看一眼状态它会用红字标出没暂存的改动绿字标出已暂存的改动。新手经常犯的错是git add完忘了commit以为已经保存了其实只是放进了暂存区。3.3 提交信息怎么写才算合格-m后面那句话不是随便写的它是给未来的你看的。我见过太多提交信息写修改更新fix的过一个月自己都不知道改了啥。我的写法习惯是第一行用一句话说清楚这次提交干了什么控制在 50 字以内如果一句话说不完空一行再写详细说明。比如修复登录页在 Safari 下按钮错位的问题 原因是 flex 布局在旧版 Safari 下需要加 -webkit- 前缀 给按钮容器补上后测试通过。这样写的好处是git log一眼扫过去能看懂每次提交的主题需要细节时再看正文。团队协作时别人 review 你的代码也能快速理解你的意图。还有一个实用技巧提交信息里可以写关联的工单号比如修复登录超时问题 #1234很多平台会自动把提交和工单关联起来追溯起来非常方便。3.4 查看历史log 的几种常用姿势git log是查看提交历史的命令但默认输出信息量太大新手容易看花眼。我推荐几个常用参数。git log --oneline # 每个提交压成一行最常用 git log --oneline --graph # 加上分支合并的图形化展示 git log -5 # 只看最近 5 条 git log --author名字 # 只看某人的提交 git log 文件名 # 只看某个文件的改动历史--oneline是我用得最多的输出像这样a1b2c3d 修复登录页按钮错位 e4f5g6h 新增用户头像上传功能 i7j8k9l 初始化项目前面那串字符是提交的身份证号叫 commit hash后面回退的时候要用到。--graph在分支多的时候特别有用它用字符画出分支的分叉和合并一眼就能看出项目是怎么演进的。提示如果git log输出太长卡在了一个冒号提示符那里按q就能退出。这是分页器在起作用不是卡死了新手经常在这里慌。4. 分支Git 最值钱的功能也是最容易用错的功能4.1 分支的本质一个可以移动的指针很多人觉得分支很神秘其实它的本质简单到离谱分支就是一个指向某次提交的指针。你建一个分支就是新建一个指针指向当前提交你在分支上提交指针就往前移动一格。理解这一点很多操作就顺了。比如切换分支其实就是把 HEAD当前所在位置的标记指向另一个指针合并分支就是把两个指针指向的历史合到一起。为什么这个设计厉害因为它意味着建分支的成本极低。在 Git 里建一个分支几乎是瞬间完成的不复制任何文件只是写一个 41 字节的指针。所以 Git 鼓励你多开分支想试什么新东西就开一个试完不满意直接删主线完全不受影响。对比一下老式的版本控制工具建分支要复制整个项目目录慢且占空间所以那时候大家都不敢随便开分支。Git 把这个成本降到接近零工作方式就彻底变了。4.2 分支的日常操作建、切、看、删常用命令就这几个git branch # 列出所有本地分支当前分支前面有星号 git branch 新分支名 # 基于当前提交建一个新分支 git checkout 分支名 # 切换到指定分支 git checkout -b 新分支名 # 建一个新分支并立刻切过去最常用 git branch -d 分支名 # 删除已合并的分支 git branch -D 分支名 # 强制删除未合并的分支git checkout -b这个组合命令是我用得最多的建分支和切换一步到位。新版本 Git 还提供了git switch命令专门用来切分支语义更清晰git switch 分支名 git switch -c 新分支名checkout和switch功能上有重叠switch是后来加的专门管分支切换避免checkout一个命令干太多事造成混淆。你用哪个都行团队里统一就好。删除分支时要注意-d只能删已经合并的分支如果分支上有没合并的提交Git 会拦着你不让删这是保护机制。确实想删就用-D但删之前想清楚那些提交可能就找不回来了其实还能通过 reflog 找回但那是进阶话题。4.3 分支命名和分支策略的实战建议分支名怎么起团队最好有个约定。我见过比较清晰的几种命名方式功能分支feature/用户登录或feature/login修复分支fix/登录超时或bugfix/login-timeout发布分支release/1.2.0紧急修复hotfix/支付崩溃用斜杠分层的好处是git branch列出来时同类分支会排在一起一目了然。纯中文分支名技术上没问题但有些平台或工具对中文支持不好我一般建议用英文加短横线。分支策略上小团队最简单的是主干开发加功能分支main分支始终保持可发布状态任何人做新功能都从main切一个功能分支出去做完合并回来。大一点的团队可能会用develop作为集成分支main只放正式发布版本功能分支先合到develop测试通过再合到main。注意不管用哪种策略有一条铁律——不要在 main 分支上直接改代码。main 是大家的公共财产直接在上面改容易把别人的工作搞乱。养成干活先切分支的习惯能避免 90% 的协作事故。4.4 合并分支的两种方式merge 和 rebase把分支合回来有两种方式这是新手最容易搞混的地方我重点讲。merge的做法是把两个分支的历史合到一起如果两边都有新提交Git 会自动生成一个合并提交来记录这次合并。历史会呈现分叉再汇合的形状。rebase的做法是把你分支上的提交一个个摘下来重新接到目标分支的最新提交后面。历史会变成一条直线看起来像你一直在目标分支上顺序开发一样。用哪个我的经验是场景推荐方式原因功能分支合并回主干merge保留分支存在的痕迹历史真实本地分支同步主干最新代码rebase让本地历史保持整洁避免无意义的合并提交已经推送到远程的公共分支绝对不要 rebase会改写历史导致别人拉取时冲突个人本地整理提交rebase可以合并琐碎提交让历史更清晰rebase 有个大坑它会改写提交的 hash。如果你 rebase 了一个已经推送到远程、别人也在用的分支别人再拉取时历史就对不上了会引发一堆冲突。所以记住一句话只 rebase 自己本地、还没推送的提交。5. 远程协作从单机玩家到团队作战5.1 关联远程仓库和第一次推送本地仓库建好后要跟远程仓库建立联系命令是git remote add origin 远程仓库地址 git remote -v # 查看已关联的远程 git push -u origin main # 第一次推送-u 记住关联关系origin是远程仓库的默认别名你可以改成别的名字但大家都用 origin没必要标新立异。-u参数的作用是把本地 main 分支和远程 main 分支关联起来之后你在这个分支上直接敲git push和git pull就行不用再指定远程和分支名。远程仓库地址有两种协议HTTPS 和 SSH。HTTPS 用起来简单但每次推送要输账号密码现在多数平台用令牌代替密码。SSH 需要先配置密钥配好之后免密推送一劳永逸。团队内部一般推荐 SSH配置一次省心很久。5.2 拉取、推送、冲突协作的日常循环团队协作的日常循环基本是这样的git pull # 先把远程最新代码拉下来 # 干活改文件 git add . git commit -m 说明 git push # 推上去看起来简单但git pull这一步经常出问题。git pull实际上是两个动作的合体先git fetch把远程最新内容下载到本地再git merge合并到你当前分支。如果远程和本地都改了同一个文件的同一部分合并时就会冲突。冲突长什么样Git 会在文件里插入这样的标记 HEAD 你本地的内容 远程的内容 远程分支你需要手动决定保留哪部分把标记删掉改成最终想要的样子然后git add这个文件再git commit完成合并。这个过程第一次遇到会慌其实就是在问你这两段你想留哪个你手动编辑成想要的结果就行。提示解决冲突时不要怕Git 不会自动帮你选它把决定权交给你。改完之后一定要跑一遍测试确认合并结果是对的因为冲突解决错了很容易引入 bug。5.3 减少冲突的实操习惯冲突虽然能解决但解决起来费时费力最好的办法是少产生冲突。我总结几个习惯第一勤拉取。每天开工前先git pull别等攒了一周才拉那时候冲突会多到你想哭。第二小步提交、小步推送。一个功能拆成几次提交做完一小块就推一次别憋一个大招。改动越小跟别人冲突的概率越低。第三别动别人的文件。如果你发现要改的文件别人也在改先沟通一下看能不能分工或者错开时间。第四功能分支生命周期要短。一个功能分支从建到合并最好控制在几天内拖得越久跟主干偏离越大合并时冲突越多。第五合并前先同步主干。在功能分支上先git merge main或者git rebase main把主干最新改动合进来在本地解决完冲突再推这样主干上的合并就干净了。5.4 代码评审和合并请求的基本流程团队协作里功能分支做完不是直接合到主干而是先发一个合并请求不同平台叫法不同有的叫 Pull Request有的叫 Merge Request让同事 review 一下。这个流程的价值在于多一双眼睛看代码能提前发现 bug、风格问题、安全隐患。review 的人可以在具体某一行上留评论作者根据评论修改改完再推评论会自动关联到新的提交上。作为作者发合并请求时写清楚这几件事这个改动解决了什么问题、怎么实现的、测试情况如何、有没有需要特别注意的地方。作为 reviewer重点看逻辑对不对、边界情况处理了没、有没有明显的性能问题、命名和风格是否符合团队规范。这个流程刚开始会觉得麻烦但它是团队代码质量的重要保障。我待过的团队里坚持做 review 的线上事故明显少。6. 新手最容易踩的坑和救命命令6.1 提交错了、提交多了、提交漏了怎么办提交信息写错了用git commit --amend -m 新的提交信息这个命令会修改最近一次提交的信息。如果只是想补充几个文件到最近一次提交里先git add那些文件再git commit --amend --no-edit--no-edit表示不改提交信息。提交漏了文件同样用git add加上git commit --amend --no-edit。想撤销最近一次提交但保留改动用git reset --soft HEAD~1这会把最近一次提交撤掉但改动还在暂存区你可以重新组织再提交。如果把--soft换成--mixed默认改动会回到工作区但不在暂存区换成--hard改动直接丢弃这个要慎用。注意--amend和reset都会改写历史如果那次提交已经推送到远程改完再推需要强制推送而强制推送会影响别人。所以这些操作尽量在推送之前做。6.2 改崩了想回到某个历史版本如果只是想让某个文件回到历史版本用git checkout 提交号 -- 文件名如果想让整个项目回到某个历史提交的状态用git reset --hard 提交号但--hard会丢弃之后的所有改动用之前想清楚。更安全的做法是新建一个分支指向那个历史提交先看看再说git checkout -b 临时分支 提交号这样你可以在临时分支上检查历史状态确认没问题再决定怎么处理主线不受影响。还有一个救命命令是git reflog它记录了 HEAD 的所有移动历史包括那些你以为已经丢失的提交。如果你不小心reset --hard删掉了东西用git reflog找到那个提交号再git reset --hard 提交号就能找回来。这个命令救过我好几次强烈建议记住。6.3 那些让人一脸懵的报错和应对新手最常遇到的几个报错我列出来Your local changes would be overwritten by merge你想切换分支或拉取但本地有未提交的改动会冲突。解决办法是先提交或暂存git stash本地改动再操作。fatal: refusing to merge unrelated histories两个仓库的历史没有共同祖先常见于把两个独立初始化的仓库合并。加--allow-unrelated-histories参数可以强制合并但要想清楚是不是真的需要。Permission denied (publickey)SSH 密钥没配好或者没加到平台账号里。检查密钥是否生成、是否添加到平台的 SSH 设置里。Updates were rejected because the remote contains work that you do not have远程有你本地没有的提交直接推会被拒。先git pull把远程内容拉下来合并再推。detached HEAD你 checkout 到了一个具体的提交号而不是分支名处于游离状态。这时候的提交不属于任何分支容易丢。想保留就git switch -c 新分支名建个分支接住。6.4 暂存和忽略两个提升效率的小工具git stash用来临时保存未提交的改动让你能干净地切换分支。比如你改到一半突然要去修个紧急 bug又不想把半成品提交就可以git stash # 把当前改动存起来 # 切分支修 bug git stash pop # 回来把改动恢复出来.gitignore文件用来告诉 Git 哪些文件不要管比如编译产物、日志、本地配置、依赖目录。这个文件很重要如果不配你会把一堆没用的文件提交进去仓库越来越臃肿。常见的忽略内容node_modules/ *.log .env dist/ .idea/提示.gitignore只对还没被跟踪的文件生效。如果一个文件已经被提交过再加到.gitignore里是不起作用的需要先用git rm --cached 文件名把它从跟踪列表里移除。7. 从会用到用顺的几个进阶习惯7.1 图形化工具和命令行的取舍命令行是 Git 的原生形态功能最全但有些操作确实不如图形界面直观比如看分支图、逐行暂存、解决复杂冲突。我的建议是日常提交、拉取、推送用命令行看历史和解决冲突可以借助图形工具。常见的图形工具有 Git 自带的gitk、跨平台的 Sourcetree、以及各种编辑器内置的 Git 面板。编辑器内置的 Git 功能现在做得很好改动的文件、逐行 diff、暂存、提交都能在编辑器里完成不用来回切窗口。但我不建议新手一上来就全靠图形工具因为图形工具会隐藏很多细节出了问题你不知道底层发生了什么。先用命令行把基本概念和流程走通再用图形工具提效这个顺序比较合理。7.2 提交粒度为什么一次提交只做一件事这个习惯我反复强调因为它对历史可读性影响巨大。一次提交只做一件事意味着修 bug 的提交里不要夹带格式调整加功能的提交里不要顺手重构无关代码。好处有三个。第一回退精准某个提交出问题直接 revert 那一个就行不会误伤别的改动。第二review 容易reviewer 一眼能看懂这次提交的意图。第三排查问题快用git log和git blame定位问题时每个提交的边界清晰。怎么做到靠暂存区。改完一堆东西后用git add只挑相关的文件或代码块放进暂存区分多次提交。编辑器里通常支持逐块暂存可以把一个文件里的不同改动分开提交非常实用。7.3 标签给重要版本打个记号标签tag用来给某个提交起一个固定的名字通常用于标记发布版本。比如git tag v1.0.0 git tag -a v1.0.0 -m 第一个正式版本 # 带说明的标签 git push origin v1.0.0 # 推送标签到远程标签和分支的区别是分支会移动标签不会。你给 v1.0.0 打了标签它就永远指向那个提交不管后面分支怎么走。发布版本、里程碑节点用标签标记将来想找回某个版本直接 checkout 标签就行比记提交号方便得多。7.4 保持仓库健康的日常维护仓库用久了会有些小问题定期做几件事能保持健康。git gc会清理仓库里的垃圾对象压缩存储仓库大的时候能明显减小体积。一般不用手动跑Git 会自动触发但仓库特别大时可以手动执行一次。git fsck用来检查仓库完整性偶尔跑一下能提前发现损坏的对象。定期清理已经合并的本地分支用git branch --merged列出已合并的分支确认后批量删除。远程分支也可以清理git remote prune origin会删掉远程已经不存在但本地还留着的分支引用。还有一点别把大文件提交进仓库。二进制文件、视频、数据集这类东西一旦提交会永久留在历史里仓库体积会爆炸。这类文件应该用专门的大文件存储方案或者干脆放在仓库外面。8. 我这些年用 Git 攒下的实在经验8.1 关于学习路径的一点真心话Git 的命令很多但真正常用的就那么十几个。新手不要试图把所有命令背下来那样既痛苦又记不住。正确的做法是先把提交、拉取、推送、分支、合并这五个动作练熟能独立完成一个完整的协作循环然后再按需学其他命令。遇到问题先查git status和git log这两个命令能告诉你当前处于什么状态、历史发生了什么大部分困惑看一眼就清楚了。实在搞不定git reflog是最后的救命稻草它记录了一切。我见过太多人因为怕把仓库搞坏而不敢操作结果一直停留在只会提交的阶段。其实 Git 的容错性比想象中强只要提交过的东西基本都能找回来。大胆用出问题再查这是学 Git 最快的方式。8.2 团队协作里那些不成文的规矩技术之外团队协作有些软性的规矩我分享几条。提交信息用团队统一的语言和格式别一个人写中文一个人写英文混在一起看着乱。分支命名也统一别有人用feature/xxx有人用dev-xxx。合并别人的分支前先看一眼对方的改动别闭着眼睛合。合并请求里该写的说明写清楚别让 reviewer 猜你的意图。遇到冲突拿不准怎么解决找改动那部分代码的同事一起看别自己瞎猜着合。合错了引入的 bug 往往很隐蔽排查起来更费劲。还有别在公共分支上强制推送。强制推送会改写历史别人本地的记录就跟远程对不上了轻则冲突重则丢代码。这个规矩在团队里基本是红线。8.3 遇到搞不定的情况先备份再折腾最后分享一个保命习惯在尝试不确定的操作之前先给当前状态留个后路。最简单的做法是建一个临时分支指向当前提交git branch backup-20240101这样不管后面怎么折腾你都能通过git checkout backup-20240101回到折腾前的状态。等确认新操作没问题了再把这个临时分支删掉。这个习惯看起来多余但真到了关键时刻能救命。我有一次在整理历史时手滑差点丢掉一整天的提交就是靠之前随手建的备份分支找回来的。花几秒钟建个备份换的是折腾时的底气这笔账怎么算都划算。Git 这东西说到底就是个工具它的价值在于让你敢改、能退、好协作。把上面这些走一遍你就能从怕用 Git变成离不开 Git。剩下的就是在实际项目里多用用着用着就顺了。
