说实话我对 Git 的态度经历过一次很大的转变最早学的时候只觉得它是一个上传代码的工具无非是git add、git commit、git push三连和网盘没什么区别。直到后来在项目里搞砸了几次分支合并、又把别人的提交弄丢过一回才明白自己之前压根没懂 Git 的底层逻辑。这篇是 Git GitHub Gitee GitLab 系列的第一篇我们把 Git 本体一次聊透。不管你是刚准备装 Git 的新手还是已经在 GitHub、Gitee 上折腾过几轮但总报错的老朋友这篇文章都值得仔细看一遍。安装、配置、核心命令、分支、合并冲突、远程关联以及那些让新手头大的git commit --amend、git reset、git revert我全部按实际使用的顺序串起来讲。1. 版本管理的本质Git 到底在解决什么问题1.1 没有 Git 之前代码备份有多痛苦先回忆一个很经典的项目现场你写了一个功能改到一半觉得不太行想退回昨天的状态。于是你手动把整个项目文件夹复制一份命名为xxx_final_v2第二天又复制一份xxx_final_v3_真的不改了。一周后项目文件夹长这样里面躺着十几个版本压缩包。更麻烦的是多人协作的场景。团队里三个人同时改同一个文件你在我改过的版本上继续写我覆盖了你的改动最后谁都不知道当前代码里哪个功能是新的、哪个逻辑被丢了。这种时候你会发现问题根本不在代码本身而在于谁在什么时候改了什么、怎么恢复上一个可用状态——这套信息完全没有被管理起来。Git 解决的就是这个核心问题给整个项目的变更过程做一份完整的、可追溯的时间线。它不是网盘那种同步一份最新文件而是把每一次改动都记录成一个节点每个节点保存当时所有文件的内容快照。你随时可以回到任何一个节点对比任意两次改动的差异甚至从某个节点拉出一条新的发展线。1.2 Git 的快照机制每个提交都是完整的项目状态有人以为 Git 的提交commit像备份软件一样只记录改动的部分其实不对。Git 每次提交保存的是当前所有文件的完整快照只不过为了省空间它会把内容相同、没有变化的文件做去重引用。也就是说每个 commit 都足够完整任何时候你都能基于它恢复整个项目的原貌。这个设计带来的一个好处是Git 的几乎所有操作都是在本地完成的。查看历史、切换分支、对比差异全部不需要联网。远程仓库GitHub、Gitee、GitLab只是在你想共享或备份时才需要同步过去。这一点很多人一开始没意识到总以为断网就不能用 Git——实际上 Git 本职工作完全不依赖网络网络只是用来和别人交换数据。另外一个关键概念是三区模型工作区你电脑上看到的文件、暂存区准备提交的改动清单、本地仓库已经提交的历史记录。后面讲add和commit时你会深刻体会这三个区的配合逻辑。1.3 Git 与 GitHub、Gitee、GitLab 的定位差异标题这么多词放一起新手最容易搞混的就是 Git 和剩下三个平台的关系。一句话总结Git 是工具本身GitHub / Gitee / GitLab 是基于 Git 的托管平台和协作平台。GitHub全球最大的开源社区项目多、生态丰富但国内网络环境下访问体验不太稳定。Gitee国内平台访问速度快对国内开发者友好码云上也有大量开源项目。GitLab更偏向企业私有化部署很多公司内部代码服务器直接搭建 GitLab团队协作功能非常完善。工具是同一个平台只是存储代码和展示协作信息的仓库房东。你的本地仓库可以和任意一个远程仓库建立关联甚至同时关联好几个。也就是说你完全可以在 Gitee 上托管一份代码再拷贝一份推到公司内部的 GitLabGit 本身没有意见。2. 安装与基础配置决定你后面少踩多少坑2.1 不同操作系统上的安装姿势Windows 用户直接到 Git 官网下载 Git for Windows安装包里自带 Git Bash 这个终端模拟器。安装时大部分选项保持默认但有一个地方要注意默认分支名那里建议把 master 改成 main这是近年社区的主流习惯也避免以后和平台默认分支不一致导致莫名奇妙的分支混乱。还有一行选择使用 Git 的方式选第一项仅从 Git Bash 使用 Git就行除非你确定自己需要从 cmd 里大量操作。macOS 用户如果你装了 Homebrew一行命令搞定brew install git如果没装 Homebrew直接下载安装包或者用 Xcode Command Line Tools 里自带的 Git 也可以不过版本可能偏旧建议还是单独装一个。安装完执行git --version确认版本号顺手把版本告诉别人时能看出新旧。Linux 用户不同的发行版管理工具不同。Debian/Ubuntu 用sudo apt update sudo apt install gitCentOS/RHEL 系用sudo yum install git或者较新的版本用sudo dnf install git。提示装完先在命令行输入git --version验证安装是否成功。这一步卡住的话后续全部白搭。2.2 用户信息、换行符、默认编辑器装上就要配的三样安装完成之后第一件事不是建仓库而是告诉 Git你是谁。这俩配置会写进每一次提交的元数据里以后在 GitHub、Gitee 甚至公司 GitLab 上看提交记录显示的就是这个名字和邮箱git config --global user.name 你的名字 git config --global user.email 你的邮箱--global表示全局生效这台机器上所有仓库都默认使用这个身份。如果某个特定项目想用另一个身份比如公司邮箱和个人邮箱分开在项目目录里执行同样的命令但去掉--global即可项目级配置会覆盖全局配置。第二件容易踩坑的事是换行符。Windows 用CRLF结尾macOS 和 Linux 用LF结尾。如果团队里有 Windows 和 macOS 两种系统容易看到整个文件全被标记为改动的壮观场面这就是换行符在捣乱。建议 Windows 用户执行git config --global core.autocrlf truemacOS / Linux 用户执行git config --global core.autocrlf input这样 Git 会在提交时自动归一化换行符避免无意义的全文件 diff。第三件是默认编辑器。Git 有时候需要你输入提交说明如果没配置编辑器它会调起 Vim。对 Vim 不熟的新手会卡在怎么输入文字、怎么退出上。一条命令切到你熟悉的编辑器git config --global core.editor code --wait这是 VS Code 的配置方式。用 Sublime 就填subl -n -w用 Notepad 就填notepad -multiInst。2.3 新仓库的两种入口init 与 clone全局配置做完你需要一个仓库。建仓库有两条完全不同的路径用途也不同。路径一从零开始的项目。在项目根目录执行git init这会在当前目录创建一个隐藏的.git文件夹也就是仓库的数据库。从此这个目录下的所有文件变更都在 Git 的管辖范围内。路径二参与已有的项目。从远程平台把整个仓库复制到本地git clone gitgithub.com:用户名/项目名.gitclone会直接把远程仓库的历史记录、所有分支一次性拉下来本地自动有了完整的 Git 仓库。之后你可以随便改、随便切分支所有操作在本地都有完整历史。这也是 Git 分布式设计最直观的体验——你拿到的不是一份最新代码而是整个项目的完整副本。3. 核心命令链路从改代码到推送远程的完整流程3.1 暂存区为什么不能一上来就 commit很多人觉得git add是多余的我改完文件直接commit不就行了这个疑问我也问过。但真实项目里你往往会在一个阶段同时改好几个文件有些改动是同一个功能的一部分有些只是一个临时的调试打印它们不该混进同一次提交。暂存区Staging Area就是用来做这件事的它允许你精心挑选哪些改动进入下一次提交。# 查看当前工作区与暂存区状态 git status # 把所有改动加入暂存区新手常用 git add . # 只把指定文件加入暂存区推荐 git add src/xxx.py # 已经暂存的内容如果改了再执行一次 add 更新暂存git add .省事是省事但在大型项目里很容易把不该提交的东西带进去。我现在的习惯是先用git status看清所有改动再逐个git add指定文件最后才提交。每次提交都应该是一个逻辑完整、描述清楚的小单元这样以后翻历史时每一行都有价值。暂存好了之后正式提交git commit -m feat: 完成用户登录接口-m后面跟的是提交说明。我见过团队规定提交信息必须按type: description的格式来写比如fix:、feat:、docs:在开源社区尤其常见。这套约定本身不复杂但能让你三个月后回看历史时一眼看出每次提交在干嘛。3.2 状态查看与历史回溯别再凭着记忆猜了提交完你怎么确认哪些文件改了、上次提交是什么靠的是一组查询命令# 查看简洁版历史 git log --oneline # 查看某个文件的提交历史 git log --oneline -- 文件名 # 查看某个文件最新的改动细节 git diff # 查看已经暂存的内容与最后一次提交的差异 git diff --cachedgit log --oneline是我最常用的命令没有之一。每行显示一个提交的短哈希值和说明信息整个项目的演进脉络一眼扫完。配合git show 哈希值可以查看某个提交改了哪些文件、具体改了什么。还有一个非常实用的选项git log --oneline --graph它会把分支结构用纯文本画出来合并关系一目了然。这个命令根本不需要图形界面工具终端里就能帮你理清思路。提示git status给你的信息足够仔细读一遍。它会明确提示当前分支、暂存了几个文件、未暂存几个文件、还有哪些未跟踪的新文件。很多人报错后第一反应是重新 clone实际上大半问题git status已经把答案写出来了。3.3 分支Git 最值钱的设计如果说只挑一个理由让你必须用 Git我会选分支branch。它的核心价值是在不影响主线路的前提下同时推进多条开发线。举个例子你正在写用户注册功能主分支main上突然发现一个线上 bug 要紧急修复。没有分支的版本管理方式下你的选择要么是先把写到一半的代码临时注释掉要么是手动备份整个文件夹。有分支之后你只需要# 基于当前状态新建并切换到修复分支 git checkout -b hotfix/login-bug # ...改完代码提交切回主分支 git checkout main # 把修复合并回主分支 git merge hotfix/login-bug # 不再需要的分支可以删除 git branch -d hotfix/login-bug新建分支的成本几乎为零所以 Git 社区有一个黄金习惯每个功能一个分支而不是所有人都在 main 上硬堆。分支名一般就是功能的简短描述别人一看就知道这条线在干什么。切换分支时还有一个很多人反复踩的坑如果当前工作区有未提交的改动git checkout可能被拒绝或者把改动带到另一个分支上。最安全的做法是养成切换分支前先git status看一眼的习惯或者把未完成的改动用git stash暂时收起来这个后面会细说。4. 提交后的补救amend、reset 与 revert 的适用边界4.1 git commit --amend满足你对改近一次提交的想象有一次我在一个开源项目里提交代码提交信息把 fix 拼成了 fxi提交完才看见。这个错误很明显不值得为它多刷一条提交记录出来。这时候就该用git commit --amend。它做的事情是把当前暂存区的改动合并进最近一次提交并允许你重写提交说明。# 只改最近一次提交的说明 git commit --amend -m fix: 正确拼写 # 漏掉了一个文件想把它补进上一个提交 git add 漏掉的文件 git commit --amend --no-edit第二种用法我在本地开发时很常用写完代码提交完才发现少提交了某个文件一条命令就能把漏网之鱼补进上一个提交而且保持原来的提交说明不变。但这里有一个必须记住的界限amend 会生成一个全新的 commit 对象哈希值变了。如果这个提交已经 push 到远程仓库、并且别人已经拉取过那就不要再用 amend 了否则会出现你的本地历史和远程历史不一致的尴尬局面别人 pull 时会看到一条本不该存在的重复历史团队里会出现到底谁改了什么的分歧。你自己的分支、还没有推送过的提交随便 amend 没问题。4.2 reset 的三种模式软、混合、硬有时候不只是改提交信息的问题而是整个提交都搞砸了要回退。git reset就是干这个的。git reset --soft HEAD~1 git reset --mixed HEAD~1 # 这是默认模式 git reset --hard HEAD~1这三个模式的区别在于回退之后文件处于什么状态模式工作区文件暂存区适用场景--soft保留改动保留在暂存区想重新组织提交--mixed默认保留改动清空暂存区想重新整理文件再提交--hard丢弃全部改动清空暂存区确定不要这些改动了HEAD~1表示上一个提交HEAD~2就是上上个。也可以用具体的提交哈希值。我的建议是不到万不得已不要用--hard。它会把工作区的文件内容也一并还原你手头所有未提交的改动全都没了这种删除是真正的不可恢复。如果只是想撤销一个提交但还想保留里面的改动--mixed通常才是正确选择。4.3 已经推送远程reset 还是 revert本地回退一时爽但如果提交已经推到远程情况完全不同了。你git reset之后直接git push --force看起来远程历史被改了但团队其他人的本地仓库还保留着旧提交。下次他们一 push被 抹掉 的提交又会冒出来甚至把别人的工作顶掉。这种事故在团队协作里是灾难级的。正确的做法是用git revertgit revert HEAD~1revert不是抹掉历史而是新增一个反向提交把之前某个提交的改动效果撤销掉。原来的提交还在历史记录里新提交记录我撤销了它。这样所有协作者的本地历史都能平滑同步不会有任何冲突和幽灵提交。所以规则其实很简单记住这一条就够了提交没有推送远程用reset随便折腾历史。提交已经推送远程、且别人可能拉取过用revert保留历史原貌新增反向提交。5. 分支合并与冲突处理每个人都会遇到的高频事故5.1 冲突到底是怎么产生的假设你和同事同时在main分支的第 100 行附近做修改。你改完先合并进 main他也改完要合并进来系统发现这一行有两个不同的版本无法自动判断该听谁的。于是 Git 停止合并把你带入冲突状态需要人来拍板。git merge 分支名 # 输出: CONFLICT (content): Merge conflict in src/app.js冲突不是错误它是 Git 在如实告诉你我没法替你决定。但凡有两条分支改动过同一处地方迟早会遇到一次。5.2 冲突标记怎么读打开冲突文件你会看到一堆特殊标记 HEAD 这是当前分支main里的版本 这是你正要合并进来的分支里的版本 feature/login和之间是我这一侧的代码和之间是对方那侧的代码。你需要做的不是简单选一边而是理解两侧改动的意图合并成一份正确的代码然后把标记删干净。处理完之后git add 冲突文件 git commit -m merge: 解决登录逻辑冲突注意解决冲突时不能把整个文件推给搭档说你自己看至少要理解冲突两侧各自在改什么逻辑。只保留一侧代码默认丢弃另一侧的改动这种偷懒方式往往会在后续制造更难查的功能 bug。5.3 merge 和 rebase 的取舍少折腾花活除了git merge还有一个高频命令git rebase。它也能把分支的改动整合到主线但方式完全不同merge会产生一个合并提交保留两条分支的汇合痕迹rebase则把你这边的提交就地移到目标分支的顶端历史看起来像一条直线。社区里对这两者的讨论能写一本书但我的建议很朴素团队协作以merge为主rebase只用来整理你自己还没推送的本地提交。原因很简单——rebase同样是改写历史会改变提交哈希。一旦分支被别人拉取过你 rebase 再强推和 reset 一样会制造历史分裂。很多团队明令禁止对共享分支执行 rebase就是这个道理。如果你只是想让自己的功能分支在合并前保持整洁去掉临时提交、合并成几个有意义的 commit在本地偷偷rebase -i没问题但 push 出去之后忘了它。6. 与远程平台联动SSH 密钥、clone 与 push6.1 SSH 密钥配一次永久免密用 HTTPS 方式操作远程仓库的时候平台现在都不再支持单纯的密码验证而是要求使用 Personal Access Token临时令牌来替代密码。这东西有效期一过又要重新生成很麻烦。所以我个人强烈建议直接用 SSH 密钥认证配一次以后就再也不用输密码了。生成密钥ssh-keygen -t rsa -b 4096 -C 你的邮箱执行后一路回车默认保存在~/.ssh/id_rsa和~/.ssh/id_rsa.pub。私钥留在自己机器里公钥内容可以放心加到 GitHub、Gitee、GitLab 的 SSH Key 设置里cat ~/.ssh/id_rsa.pub在 GitHub、Gitee、GitLab 三个平台各自找到 SSH Keys 或公钥设置位置把输出内容整个粘贴进去保存。验证是否成功ssh -T gitgithub.com如果是 Gitee就把github.com换成gitee.comGitLab 则换成你们的 GitLab 域名。看到欢迎语说明通了。以后 clone 仓库的时候只要选 SSH 地址形如gitgithub.com:用户名/仓库名.git就不再需要密码了。6.2 clone 与 remote add两条关联远程仓库的路径场景一远程仓库已经存在你要把代码弄到本地。直接用git clone就行它会自动把远程仓库地址记录为一个名叫origin的远程连接。场景二你本地已经有一个项目想把它推到远程平台的空仓库。先在 GitHub、Gitee 或 GitLab 上创建空仓库拿到 SSH 地址然后# 把本地仓库与远程关联 git remote add origin gitgithub.com:用户名/项目名.git # 第一次推送指定当前分支并建立追踪关系 git push -u origin main-u全称是--set-upstream作用是让本地 main 分支记住它的上游是远程 origin/main。以后你再执行git push或git pull就不用带参数了。日常更新流程也很简单# 拉取远程最新改动 git pull # 推送本地提交 git push对于新项目建议按这个顺序先在平台上建好空仓库README 和 .gitignore 先不加再在本地git init、添加代码、提交最后关联远程并推送。这样能避开先初始化再 push 被拒绝的常见尴尬。6.3 平台选择GitHub、Gitee、GitLab 怎么选从本地 Git 的角度看三个平台做的事情一模一样接收你的推送、保存历史、提供网页版浏览和协作功能。区别主要在于生态和访问体验。找开源项目、看别人怎么实现某些功能GitHub 是全球最大的代码海洋这点没得替代。国内开发者日常备份、托管自己的项目、搭建个人主页Gitee 速度快而且国内网络环境下操作非常顺仓库秒开对新手尤其友好。公司内部私有代码库GitLab 是几套私有化方案里社区版功能最全的CI/CD、权限管理、代码审查都能在一个系统里跑通。有一件很实用的事你可以在一个本地仓库上同时配置多个远程。比如主仓库放 GitHub同时在 Gitee 上也放一份镜像这样既多一层备份又不影响国内浏览和拉取git remote add gitee gitgitee.com:用户名/项目名.git git push gitee main这个技巧在很多团队里被用来解决外部开源 内部快速访问的问题本身也是 Git 分布式特性的自然延伸。7. 效率与习惯IDE 集成、别名、stash 与 .gitignore7.1 IDEA 和 VS Code 里的 Git 面板命令行熟练之后IDE 内嵌的 Git 面板其实是很好的效率放大器。IDEAIntelliJ里从导航栏File - New - Project from Version Control粘贴 Git 地址就能直接拉取项目到本地底部工具栏的 Commit 面板会清晰列出所有改动文件提交信息、amend、push 都能点按钮完成。VS Code 左侧源代码管理面板也一样文件改动、暂存、提交、拉取推送都有对应按钮。我的使用习惯是日常读代码、查改动用 IDE 面板关键时刻复杂冲突、reset、revert回到命令行。原因很简单IDE 面板隐藏了细节比如它不会明确告诉你amend会改变哈希、也不会提醒推送已远程的提交不要 revert。IDE 是给你干活的命令行才是让你真正理解仓库状态的地方。7.2 常用别名配置Git 允许你给命令起别名把高频命令缩成几个字母git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status git config --global alias.lg log --oneline --graph --all配置完之后git st、git co、git lg用起来很顺手执行频率一下子就上来了。别名的存在不是为了炫技而是让随手查看状态这个动作成本降下来。别小看这个习惯频繁git status、git lg的人出大事故的概率明显比闷头改代码的人低。7.3 stash 与 .gitignore两个每天都在帮你的功能git stash解决的是这个场景你手头的功能改到一半临时接到一个紧急需求要切换分支。当前工作区还没到可以提交的程度直接切换分支又怕改动弄丢。此时# 暂存当前所有未提交的改动 git stash # 切分支处理紧急事情... # 回到原分支恢复改动 git stash popstash本质是一个临时栈把工作区和暂存区的改动保存起来给它们一个寄存处。多积累几次还可以git stash list查看、git stash apply精确恢复某一条。.gitignore则是另一种保护项目里总有不想被 Git 跟踪的文件比如本地配置、密钥、编译产物、IDE 设置目录。在项目根目录建一个.gitignore文件写上规则node_modules/ dist/ .env *.log .idea/ .vscode/这些文件和目录从此就会被 Git 自动忽略不会再出现在git status里。如果你是在项目早期就建好.gitignore后面能省掉很多误把密钥传到 GitHub 上的惨案。注意到.idea/和.vscode/了吗IDE 配置属于个人习惯不应该进版本库团队里每人编辑器不同上传了反而会频繁制造无意义的 diff。大文件方面也顺便提一句Git 本身不适合作大文件管理文本代码没问题但动辄上百 MB 的设计稿、数据集、二进制安装包放进 Git 仓库仓库体积会迅速膨胀clone 越来越慢。如果确实要版本化管理大文件方向是了解 Git LFSLarge File Storage或者考虑改用其他对象存储方案。Gitee 这类平台对单文件大小也有限制遇到上传大文件失败时先想清楚这个文件真的应该进版本库吗很多时候答案是不该。Git 本身的学习曲线并不陡知识密度最高的其实就集中在三区模型、分支结构、历史改写、远程协作四件事上。把文章里这些命令配合自己的项目各试一遍尤其是刻意制造一次冲突、再亲手解决它基本就能从会用跨到用明白。下一篇我们单独聊 GitHub 的协作玩法包括开源项目的提交流程、PR 和 issue 的完整处理链路到时候见。