Git 这个东西我见过太多人卡在同一个地方本地代码写得飞起一到要提交、要协作、要回滚整个人就懵了。命令行里git status一跑红彤彤一片不知道该add哪个、该不该commit、push上去会不会把别人的代码冲掉。更别提第一次打开一个开源仓库的页面满屏的 Issues、Pull Requests、Fork、Star看着像天书。这篇东西就是写给这个阶段的你——刚学完 Java 基础语法能写个控制台小工具但还没真正用 Git 管过自己代码、也没在开源社区里动过手的人。我会把 Git 这套工具从“为什么需要它”讲到“怎么在真实项目里用起来”中间穿插我自己踩过的坑和带新人时反复被问到的点。核心关键词就三个版本控制、本地仓库、远程协作你把这三点吃透Git 就不再是拦路虎而是一个你每天都会主动打开的工具。1. 先想清楚 Git 到底在替你管什么很多人学 Git 的方式是背命令git init、git add、git commit、git push背完一圈发现还是不会用。问题出在没搞明白它管理的对象是什么。Git 管的不是“文件”而是“文件在某个时刻的快照”以及这些快照之间的父子关系。你每做一次提交Git 就把当前所有被跟踪文件的内容打包成一个快照存起来并记录它的上一个快照是谁。这一串快照连起来就是你的项目历史。1.1 快照思维为什么 Git 不怕你改坏文件理解“快照”这个概念比记十条命令都值。假设你写了一个Calculator.java第一版能算加法提交一次得到快照 A。然后你改代码加了个减法提交得到快照 BB 的父节点是 A。接着你手滑把加法逻辑删了提交得到快照 C。这时候你发现坏了想回到能算加法的状态——因为快照 A 完整存在你随时可以把工作区恢复成 A 的样子。这就是版本控制的本质价值任何一次提交都是一个可完整还原的存档点。对比一下没有版本控制的日子你可能会把文件命名成Calculator.java、Calculator_改.java、Calculator_最终版.java、Calculator_最终版2.java。这种方式的问题不在于丑而在于你根本说不清“最终版2”和“最终版”之间到底改了什么也没法把两个版本的改动合并。Git 用快照 父子链的方式把“改了什么”变成可计算、可对比、可回退的结构化数据。提示快照不是把整个项目复制一遍存起来。Git 底层用内容寻址的方式存储内容相同的文件只存一份所以哪怕你提交一千次仓库体积也不会爆炸。这一点新手不用深究实现但知道它“不会因为提交多而变卡变胖”能让你更放心地勤提交。1.2 三个区域工作区、暂存区、本地仓库这是新手最容易绕晕的地方我用一个生活化的类比讲清楚。把 Git 想象成寄快递工作区是你桌上正在改的那份文件随便涂改还没打包。暂存区是你把要寄的东西放进快递盒这一步叫git add。放进去之后还能拿出来换但盒子里的东西才是“这次要寄的”。本地仓库是快递已经封箱、贴单、录入系统这一步叫git commit。封箱之后这一单就固定了有单号commit hash可以查、可以退。为什么要有暂存区这个中间层直接提交不行吗行但你会失去“挑选”的能力。真实开发里你经常同时改了三处修了个 bug、加了个日志、顺手格式化了两个文件。这三件事逻辑上应该分成三次提交方便以后单独回滚或审查。暂存区就是让你能把改动拆开、分批封箱的工具。我带过的新人里十个有八个一开始觉得暂存区多余等第一次需要“只提交 bug 修复、不提交调试代码”时才明白它的好。1.3 分支不是高级功能是日常操作很多人把分支当成“团队协作才用的东西”自己一个人写代码从不建分支。这是个挺亏的习惯。分支在 Git 里本质上只是一个指向某个快照的可移动指针创建和切换的成本极低几乎瞬间完成不复制文件。它的真正用途是隔离实验你想试一个新写法又怕把能跑的版本搞坏就开个分支去折腾折腾成功就合并回来折腾失败直接删掉主线上干干净净。我自己的习惯是哪怕一个人写个小工具只要要动核心逻辑就先git switch -c try-new-parser开个分支。这个动作花不了两秒但能让我在改崩的时候毫无心理负担地git switch main回到可用状态。这种“敢改”的安全感是版本控制给开发者最实在的礼物。2. 本地仓库从初始化到第一次提交的完整链路这一节我把从零建仓库到提交第一版代码的全过程走一遍每一步都说清楚在干什么、为什么这么干。你跟着敲一遍本地这套就通了。2.1 初始化与身份配置别跳过这一步在项目根目录执行git initGit 会在当前目录下生成一个隐藏的.git文件夹你的普通目录就变成了一个 Git 仓库。这个文件夹里存着所有版本数据删了它仓库就没了工作区文件还在所以别手贱去动它。初始化之后第一件事是配置身份因为每次提交都要记录“谁提交的”git config --global user.name 你的名字 git config --global user.email 你的邮箱--global表示全局配置对这台机器上所有仓库生效。如果你在某个仓库里想用不同身份去掉--global在该仓库内单独配。这里有个坑要提醒邮箱最好和你之后要用的代码托管平台账号邮箱保持一致否则平台上的提交记录可能认不出是你贡献统计里就不显示。我见过有人本地提交了几十次平台上头像一直是灰的查半天就是邮箱对不上。2.2 看懂 git status 的输出git status是你用得最频繁的命令没有之一。它告诉你当前工作区、暂存区、仓库三者之间的差异状态。刚 init 完跑一次你会看到类似“No commits yet”和一堆“Untracked files”的提示。未跟踪untracked意思是这些文件 Git 还没开始管。这里要引出.gitignore文件。有些文件你永远不想提交编译产物*.class、IDE 配置.idea/、*.iml、本地日志、含密码的配置文件。在项目根目录建一个.gitignore把这些模式写进去Git 就会自动忽略它们。Java 项目一个够用的起步版本*.class target/ out/ .idea/ *.iml *.log .DS_Store注意.gitignore只对“还没被跟踪”的文件生效。如果你已经把某个文件add过并提交了之后再写进.gitignore是不起作用的得先用git rm --cached 文件名把它从跟踪列表里移除再提交一次。这个坑我踩过当时纳闷了半天为什么忽略了还在。2.3 add 与 commit把改动封箱假设你写好了Calculator.javagit status里它是 untracked。执行git add Calculator.java它进入暂存区状态变成“Changes to be committed”。想一次加所有改动用git add .但我建议新手前期尽量显式指定文件名逼自己看清楚每次到底提交了什么。提交用git commit -m 说明这次改了什么。关于提交信息我给个实在的建议别写“修改”“更新”“fix”这种等于没写的话。半年后你回头看历史一条“修复除法除零时抛异常未捕获的问题”能让你三秒定位一条“改了下”只能让你重新翻代码。提交信息的质量直接决定你未来排查问题的效率。提交完再跑git status应该显示“nothing to commit, working tree clean”说明工作区、暂存区、仓库三者一致了。到这一步你的第一个本地快照就存好了。2.4 log 与 diff回看历史的两把工具git log看提交历史默认输出比较啰嗦每个提交占好几行。我常用git log --oneline一行一个提交前面是短 hash后面是提交信息扫一眼就能看清脉络。想更直观可以加--graph分支合并关系会用字符画出来。git diff看差异分几种用法要分清命令对比对象典型场景git diff工作区 vs 暂存区看还没 add 的改动git diff --staged暂存区 vs 最近提交看这次要提交什么git diff HEAD工作区 vs 最近提交看所有未提交改动这三个的区别新手经常混。记住一句话git diff不带参数永远比的是“工作区”和“暂存区”也就是你改了但还没放进快递盒的部分。要看你已经放进盒子的东西加--staged。3. 把本地仓库接到远程托管平台上的第一次亮相本地能提交只是第一步代码最终要放到远程仓库才能备份、协作、展示。这一节讲怎么把一个本地仓库推到一个代码托管平台上以及这过程中几个容易出错的环节。3.1 远程仓库的建立与关联在托管平台上新建一个仓库平台会给你一个仓库地址HTTPS 或 SSH 两种形式。然后在本地执行git remote add origin 仓库地址 git branch -M main git push -u origin main逐条解释remote add origin是给远程地址起个别名叫origin约定俗成的名字你也可以叫别的但没必要branch -M main把当前分支重命名为main现在平台默认主分支多叫 main老版本 Git 默认叫 master统一一下省得混乱push -u里的-u是建立本地分支和远程分支的追踪关系设过一次之后以后直接git push就行不用每次写全。这里有个高频问题push的时候报认证失败。HTTPS 方式下很多平台已经不支持直接用账号密码需要用访问令牌token代替密码。SSH 方式则需要你在本地生成密钥对把公钥配置到平台账号里。两种方式选一种即可SSH 配一次以后免输密码长期用更省事HTTPS 上手快但每次可能要处理凭证。我一般建议新手先用 HTTPS 跑通流程等熟了再换 SSH。3.2 clone拿到别人的仓库参与开源或者接手项目第一步是git clone 仓库地址。它会把远程仓库完整拉到本地包括所有历史提交并自动把origin配好。clone 下来之后你就在一个能直接提交的本地仓库里了。clone 有个参数值得知道--depth 1叫浅克隆只拉最近一次提交不拉完整历史。仓库特别大、历史特别长的时候浅克隆能省很多时间和空间。代价是你本地没有完整历史某些需要回溯的操作做不了。日常看代码、跑项目浅克隆够用要深入参与开发还是完整克隆。3.3 fetch 与 pull拉取更新的两种姿势远程仓库被别人更新了你本地要同步用git fetch或git pull。这两个的区别值得讲清楚git fetch只把远程的新提交下载到本地但不合并到你当前分支。你可以先git log origin/main看看别人改了什么确认没问题再手动合并。git pull等于fetch加merge下载完直接合并进当前分支。新手图省事爱用pull但如果你本地有未提交的改动pull可能触发合并冲突处理起来手忙脚乱。我的习惯是本地有干净工作区时用pull本地有改动或者想先看看再决定时先fetch再评估。多这一步能避免不少“拉下来一堆冲突不知道怎么收场”的窘境。4. 分支与合并一个人也值得用的隔离手段前面提过分支的价值这一节把创建、切换、合并、删除的完整流程走一遍并讲清楚合并冲突到底是怎么回事。4.1 建分支、切分支、看分支git branch # 列出本地分支当前分支前有 * git switch -c feature-x # 新建并切换到 feature-x 分支 git switch main # 切回 main老教程里常用git checkout -b效果一样switch是后来分出来的更语义化的命令专门管分支切换不容易和“恢复文件”的 checkout 混淆建议用新的。在feature-x上提交几次切回main你会发现main上完全看不到那些提交——因为分支就是指针main还指着原来的快照。这就是隔离生效了。4.2 merge把分支合回来在main上执行git merge feature-xGit 会尝试把feature-x的改动合并进来。如果两个分支改的是不同文件的不同位置Git 自动完成生成一个合并提交。如果改到了同一处就会冲突。冲突不可怕它的本质是“Git 没法替你决定保留哪个版本”。打开冲突文件你会看到、、标记出的两段内容手动改成你想要的结果删掉这些标记然后git add该文件、git commit完成合并。整个过程的关键是冲突标记是给人看的改完必须删干净否则标记本身会被当成代码提交进去。我见过有人漏删标记导致编译报错排查半天。4.3 删除分支与“合并了吗”的判断分支合并完就可以删git branch -d feature-x。-d是安全删除如果这个分支还有没合并的提交Git 会拒绝并提醒你防止误删丢代码。确认不要了想强删用-D但用之前一定想清楚。这里分享一个实用判断删分支前跑git branch --merged列出所有已经合并进当前分支的分支这些删了绝对安全。没列出来的就是还有独立提交的删之前得掂量。5. 开源社区里那些按钮背后的 Git 动作第一次逛开源仓库页面上 Star、Fork、Watch、Issues、Pull Requests 一堆入口很多人不知道从哪下手。这一节把这些概念和 Git 操作对应起来让你明白点每个按钮时背后发生了什么。5.1 Star、Watch、Fork 分别是什么Star相当于收藏加点赞纯标记不影响代码也不产生任何 Git 操作。你 Star 了某个仓库它出现在你的收藏列表里方便以后找。Watch是订阅通知仓库有新 Issue、新 PR、新评论时你会收到提醒。关注活跃项目时有用但别乱 Watch 大仓库通知会淹死你。Fork才是真正和 Git 相关的动作它在你的账号下复制一份该仓库你拥有这份副本的完整权限可以随意提交、建分支。Fork 出来的仓库和原仓库是独立的两个远程仓库你的改动不会自动进原仓库。5.2 Pull Request从 Fork 到被合并的完整路径想给一个开源项目贡献代码标准流程是这样的在平台上 Fork 目标仓库得到你自己的副本。git clone你的副本到本地。建一个描述性的分支比如fix-null-pointer-in-parser。在这个分支上改代码、提交。git push到你的 Fork 仓库。在平台上从你的分支向原仓库发起 Pull RequestPR。项目维护者审查你的改动可能提意见让你改改完再 pushPR 会自动更新。通过后由维护者合并进原仓库。这个流程里最容易忽略的是第 3 步——直接在 Fork 的主分支上改。这样做的坏处是如果维护者让你改或者你想同时做两件事主分支会变得很乱。养成“一个 PR 一个分支”的习惯是参与开源的基本素养。提示发起 PR 前先看看项目有没有贡献指南通常叫 CONTRIBUTING.md里面会写代码风格、提交信息格式、测试要求。照着做能大幅提高被合并的概率。不看的后果往往是 PR 被晾着维护者一句“请先阅读贡献指南”就把你打发了。5.3 Issue不只是报 bug 的地方Issue 常被当成 bug 报告区其实它也是提需求、讨论方案、提问的地方。提 Issue 有个基本原则先搜再提。你遇到的问题很可能已经有人提过并有解决方案重复提只会增加维护者负担。搜索关键词用报错信息里的核心词比用大白话描述更容易命中。写 Issue 时把环境操作系统、版本号、复现步骤、期望结果、实际结果写清楚。能附最小复现代码就附。我见过太多“用不了求解决”这种 Issue维护者根本无从下手最后只能关闭。反过来信息完整的 Issue 往往很快得到回应因为别人一看就知道问题在哪。6. 新手最容易栽的几个坑与应对这一节集中讲我带新人时反复见到的错误每个都说清楚原因和正确做法你对照自查能省不少时间。6.1 提交了不该提交的文件最常见的是把target/编译产物、.idea/配置、甚至含密码的配置文件提交上去了。原因通常是先git add .一把梭没看status就提交。应对办法前面讲过.gitignore提前配好add前先status扫一眼。如果已经提交了用git rm --cached 文件名移除跟踪再提交历史里的旧记录如果含敏感信息那得用更复杂的手段清理所以防患于未然比事后补救重要得多。6.2 在错误的分支上改代码写着写着发现改错分支了改动还没提交。这时候别慌git stash能把当前改动暂存起来切到正确分支后git stash pop恢复。如果已经提交了可以用git cherry-pick 提交hash把那个提交摘到正确分支再在原分支上回退。这两个命令新手可以先记住stash这一招够应付大部分“改错地方”的场景。6.3 合并冲突处理到一半想放弃冲突改到一半发现搞乱了想回到合并前的状态执行git merge --abort一切回到 merge 之前。这个命令是救命稻草记住它。同理rebase中途想放弃用git rebase --abort。遇到烂摊子先想“有没有 abort”比硬着头皮改安全。6.4 push 被拒绝远程有你没有的提交push时报“rejected”通常是因为远程分支有你本地没有的新提交别人推过或者你在平台上直接改过文件。正确做法是先git pull把远程的拉下来合并解决可能的冲突再push。千万别上来就push -f强推那会覆盖别人的提交是协作中的大忌。强推只在自己独占的分支、且明确知道后果时才能用。现象大概率原因正确处理push rejected远程有新提交先 pull 合并再 push忽略规则不生效文件已被跟踪git rm --cached后提交提交记录认不出作者邮箱与平台账号不一致改 config 邮箱冲突标记进了代码合并后没删标记搜清理7. 把 Git 用成肌肉记忆的日常习惯工具这东西看十篇教程不如自己天天用。我给几个能让你快速形成肌肉记忆的建议都是我自己实践下来有效的。第一小步提交。每完成一个能说清楚的小改动就提交一次别攒一大坨再提交。小提交的好处是历史清晰、回滚精准、冲突范围小。判断标准很简单你能用一句话准确描述这次提交干了什么就可以提交了。第二提交前必看 status 和 diff。git status看有哪些文件动了git diff --staged看具体改了什么。这个习惯能拦住绝大多数“误提交”。多花十秒省得以后清理历史。第三分支名和提交信息写人话。分支名用fix-xxx、feature-xxx这种能看出意图的格式提交信息写清楚“为什么改”而不只是“改了什么”。这些文字是写给未来的自己和协作者看的值得认真对待。第四每天开工先 pull收工前 push。养成同步习惯能避免本地和远程越差越远最后合并成大麻烦。当然前提是当天的工作到了一个可提交的状态半成品别硬推。第五遇到不懂的命令先查再敲。Git 有些命令破坏性很强比如reset --hard、clean -fd敲之前确认它到底干什么。我见过有人reset --hard把一天的工作全清了因为没搞懂它会丢弃工作区改动。不确定的时候先git stash备份一下再操作多一层保险。这套东西说到底就一句话Git 不是考试科目是每天要用的工具。你不需要背下所有命令但要把“提交、查看、分支、同步”这几个高频动作练到不用想就能敲出来。剩下的边用边查用着用着就全通了。我自己到现在也经常查某个参数怎么拼这不丢人把活干对才重要。 
长河君 · 2026/10/27 2:51:25 · 阅读 1.2k Git入门实战：从本地版本控制到远程协作与开源贡献
Git 这个东西我见过太多人卡在同一个地方本地代码写得飞起一到要提交、要协作、要回滚整个人就懵了。命令行里git status一跑红彤彤一片不知道该add哪个、该不该commit、push上去会不会把别人的代码冲掉。更别提第一次打开一个开源仓库的页面满屏的 Issues、Pull Requests、Fork、Star看着像天书。这篇东西就是写给这个阶段的你——刚学完 Java 基础语法能写个控制台小工具但还没真正用 Git 管过自己代码、也没在开源社区里动过手的人。我会把 Git 这套工具从“为什么需要它”讲到“怎么在真实项目里用起来”中间穿插我自己踩过的坑和带新人时反复被问到的点。核心关键词就三个版本控制、本地仓库、远程协作你把这三点吃透Git 就不再是拦路虎而是一个你每天都会主动打开的工具。1. 先想清楚 Git 到底在替你管什么很多人学 Git 的方式是背命令git init、git add、git commit、git push背完一圈发现还是不会用。问题出在没搞明白它管理的对象是什么。Git 管的不是“文件”而是“文件在某个时刻的快照”以及这些快照之间的父子关系。你每做一次提交Git 就把当前所有被跟踪文件的内容打包成一个快照存起来并记录它的上一个快照是谁。这一串快照连起来就是你的项目历史。1.1 快照思维为什么 Git 不怕你改坏文件理解“快照”这个概念比记十条命令都值。假设你写了一个Calculator.java第一版能算加法提交一次得到快照 A。然后你改代码加了个减法提交得到快照 BB 的父节点是 A。接着你手滑把加法逻辑删了提交得到快照 C。这时候你发现坏了想回到能算加法的状态——因为快照 A 完整存在你随时可以把工作区恢复成 A 的样子。这就是版本控制的本质价值任何一次提交都是一个可完整还原的存档点。对比一下没有版本控制的日子你可能会把文件命名成Calculator.java、Calculator_改.java、Calculator_最终版.java、Calculator_最终版2.java。这种方式的问题不在于丑而在于你根本说不清“最终版2”和“最终版”之间到底改了什么也没法把两个版本的改动合并。Git 用快照 父子链的方式把“改了什么”变成可计算、可对比、可回退的结构化数据。提示快照不是把整个项目复制一遍存起来。Git 底层用内容寻址的方式存储内容相同的文件只存一份所以哪怕你提交一千次仓库体积也不会爆炸。这一点新手不用深究实现但知道它“不会因为提交多而变卡变胖”能让你更放心地勤提交。1.2 三个区域工作区、暂存区、本地仓库这是新手最容易绕晕的地方我用一个生活化的类比讲清楚。把 Git 想象成寄快递工作区是你桌上正在改的那份文件随便涂改还没打包。暂存区是你把要寄的东西放进快递盒这一步叫git add。放进去之后还能拿出来换但盒子里的东西才是“这次要寄的”。本地仓库是快递已经封箱、贴单、录入系统这一步叫git commit。封箱之后这一单就固定了有单号commit hash可以查、可以退。为什么要有暂存区这个中间层直接提交不行吗行但你会失去“挑选”的能力。真实开发里你经常同时改了三处修了个 bug、加了个日志、顺手格式化了两个文件。这三件事逻辑上应该分成三次提交方便以后单独回滚或审查。暂存区就是让你能把改动拆开、分批封箱的工具。我带过的新人里十个有八个一开始觉得暂存区多余等第一次需要“只提交 bug 修复、不提交调试代码”时才明白它的好。1.3 分支不是高级功能是日常操作很多人把分支当成“团队协作才用的东西”自己一个人写代码从不建分支。这是个挺亏的习惯。分支在 Git 里本质上只是一个指向某个快照的可移动指针创建和切换的成本极低几乎瞬间完成不复制文件。它的真正用途是隔离实验你想试一个新写法又怕把能跑的版本搞坏就开个分支去折腾折腾成功就合并回来折腾失败直接删掉主线上干干净净。我自己的习惯是哪怕一个人写个小工具只要要动核心逻辑就先git switch -c try-new-parser开个分支。这个动作花不了两秒但能让我在改崩的时候毫无心理负担地git switch main回到可用状态。这种“敢改”的安全感是版本控制给开发者最实在的礼物。2. 本地仓库从初始化到第一次提交的完整链路这一节我把从零建仓库到提交第一版代码的全过程走一遍每一步都说清楚在干什么、为什么这么干。你跟着敲一遍本地这套就通了。2.1 初始化与身份配置别跳过这一步在项目根目录执行git initGit 会在当前目录下生成一个隐藏的.git文件夹你的普通目录就变成了一个 Git 仓库。这个文件夹里存着所有版本数据删了它仓库就没了工作区文件还在所以别手贱去动它。初始化之后第一件事是配置身份因为每次提交都要记录“谁提交的”git config --global user.name 你的名字 git config --global user.email 你的邮箱--global表示全局配置对这台机器上所有仓库生效。如果你在某个仓库里想用不同身份去掉--global在该仓库内单独配。这里有个坑要提醒邮箱最好和你之后要用的代码托管平台账号邮箱保持一致否则平台上的提交记录可能认不出是你贡献统计里就不显示。我见过有人本地提交了几十次平台上头像一直是灰的查半天就是邮箱对不上。2.2 看懂 git status 的输出git status是你用得最频繁的命令没有之一。它告诉你当前工作区、暂存区、仓库三者之间的差异状态。刚 init 完跑一次你会看到类似“No commits yet”和一堆“Untracked files”的提示。未跟踪untracked意思是这些文件 Git 还没开始管。这里要引出.gitignore文件。有些文件你永远不想提交编译产物*.class、IDE 配置.idea/、*.iml、本地日志、含密码的配置文件。在项目根目录建一个.gitignore把这些模式写进去Git 就会自动忽略它们。Java 项目一个够用的起步版本*.class target/ out/ .idea/ *.iml *.log .DS_Store注意.gitignore只对“还没被跟踪”的文件生效。如果你已经把某个文件add过并提交了之后再写进.gitignore是不起作用的得先用git rm --cached 文件名把它从跟踪列表里移除再提交一次。这个坑我踩过当时纳闷了半天为什么忽略了还在。2.3 add 与 commit把改动封箱假设你写好了Calculator.javagit status里它是 untracked。执行git add Calculator.java它进入暂存区状态变成“Changes to be committed”。想一次加所有改动用git add .但我建议新手前期尽量显式指定文件名逼自己看清楚每次到底提交了什么。提交用git commit -m 说明这次改了什么。关于提交信息我给个实在的建议别写“修改”“更新”“fix”这种等于没写的话。半年后你回头看历史一条“修复除法除零时抛异常未捕获的问题”能让你三秒定位一条“改了下”只能让你重新翻代码。提交信息的质量直接决定你未来排查问题的效率。提交完再跑git status应该显示“nothing to commit, working tree clean”说明工作区、暂存区、仓库三者一致了。到这一步你的第一个本地快照就存好了。2.4 log 与 diff回看历史的两把工具git log看提交历史默认输出比较啰嗦每个提交占好几行。我常用git log --oneline一行一个提交前面是短 hash后面是提交信息扫一眼就能看清脉络。想更直观可以加--graph分支合并关系会用字符画出来。git diff看差异分几种用法要分清命令对比对象典型场景git diff工作区 vs 暂存区看还没 add 的改动git diff --staged暂存区 vs 最近提交看这次要提交什么git diff HEAD工作区 vs 最近提交看所有未提交改动这三个的区别新手经常混。记住一句话git diff不带参数永远比的是“工作区”和“暂存区”也就是你改了但还没放进快递盒的部分。要看你已经放进盒子的东西加--staged。3. 把本地仓库接到远程托管平台上的第一次亮相本地能提交只是第一步代码最终要放到远程仓库才能备份、协作、展示。这一节讲怎么把一个本地仓库推到一个代码托管平台上以及这过程中几个容易出错的环节。3.1 远程仓库的建立与关联在托管平台上新建一个仓库平台会给你一个仓库地址HTTPS 或 SSH 两种形式。然后在本地执行git remote add origin 仓库地址 git branch -M main git push -u origin main逐条解释remote add origin是给远程地址起个别名叫origin约定俗成的名字你也可以叫别的但没必要branch -M main把当前分支重命名为main现在平台默认主分支多叫 main老版本 Git 默认叫 master统一一下省得混乱push -u里的-u是建立本地分支和远程分支的追踪关系设过一次之后以后直接git push就行不用每次写全。这里有个高频问题push的时候报认证失败。HTTPS 方式下很多平台已经不支持直接用账号密码需要用访问令牌token代替密码。SSH 方式则需要你在本地生成密钥对把公钥配置到平台账号里。两种方式选一种即可SSH 配一次以后免输密码长期用更省事HTTPS 上手快但每次可能要处理凭证。我一般建议新手先用 HTTPS 跑通流程等熟了再换 SSH。3.2 clone拿到别人的仓库参与开源或者接手项目第一步是git clone 仓库地址。它会把远程仓库完整拉到本地包括所有历史提交并自动把origin配好。clone 下来之后你就在一个能直接提交的本地仓库里了。clone 有个参数值得知道--depth 1叫浅克隆只拉最近一次提交不拉完整历史。仓库特别大、历史特别长的时候浅克隆能省很多时间和空间。代价是你本地没有完整历史某些需要回溯的操作做不了。日常看代码、跑项目浅克隆够用要深入参与开发还是完整克隆。3.3 fetch 与 pull拉取更新的两种姿势远程仓库被别人更新了你本地要同步用git fetch或git pull。这两个的区别值得讲清楚git fetch只把远程的新提交下载到本地但不合并到你当前分支。你可以先git log origin/main看看别人改了什么确认没问题再手动合并。git pull等于fetch加merge下载完直接合并进当前分支。新手图省事爱用pull但如果你本地有未提交的改动pull可能触发合并冲突处理起来手忙脚乱。我的习惯是本地有干净工作区时用pull本地有改动或者想先看看再决定时先fetch再评估。多这一步能避免不少“拉下来一堆冲突不知道怎么收场”的窘境。4. 分支与合并一个人也值得用的隔离手段前面提过分支的价值这一节把创建、切换、合并、删除的完整流程走一遍并讲清楚合并冲突到底是怎么回事。4.1 建分支、切分支、看分支git branch # 列出本地分支当前分支前有 * git switch -c feature-x # 新建并切换到 feature-x 分支 git switch main # 切回 main老教程里常用git checkout -b效果一样switch是后来分出来的更语义化的命令专门管分支切换不容易和“恢复文件”的 checkout 混淆建议用新的。在feature-x上提交几次切回main你会发现main上完全看不到那些提交——因为分支就是指针main还指着原来的快照。这就是隔离生效了。4.2 merge把分支合回来在main上执行git merge feature-xGit 会尝试把feature-x的改动合并进来。如果两个分支改的是不同文件的不同位置Git 自动完成生成一个合并提交。如果改到了同一处就会冲突。冲突不可怕它的本质是“Git 没法替你决定保留哪个版本”。打开冲突文件你会看到、、标记出的两段内容手动改成你想要的结果删掉这些标记然后git add该文件、git commit完成合并。整个过程的关键是冲突标记是给人看的改完必须删干净否则标记本身会被当成代码提交进去。我见过有人漏删标记导致编译报错排查半天。4.3 删除分支与“合并了吗”的判断分支合并完就可以删git branch -d feature-x。-d是安全删除如果这个分支还有没合并的提交Git 会拒绝并提醒你防止误删丢代码。确认不要了想强删用-D但用之前一定想清楚。这里分享一个实用判断删分支前跑git branch --merged列出所有已经合并进当前分支的分支这些删了绝对安全。没列出来的就是还有独立提交的删之前得掂量。5. 开源社区里那些按钮背后的 Git 动作第一次逛开源仓库页面上 Star、Fork、Watch、Issues、Pull Requests 一堆入口很多人不知道从哪下手。这一节把这些概念和 Git 操作对应起来让你明白点每个按钮时背后发生了什么。5.1 Star、Watch、Fork 分别是什么Star相当于收藏加点赞纯标记不影响代码也不产生任何 Git 操作。你 Star 了某个仓库它出现在你的收藏列表里方便以后找。Watch是订阅通知仓库有新 Issue、新 PR、新评论时你会收到提醒。关注活跃项目时有用但别乱 Watch 大仓库通知会淹死你。Fork才是真正和 Git 相关的动作它在你的账号下复制一份该仓库你拥有这份副本的完整权限可以随意提交、建分支。Fork 出来的仓库和原仓库是独立的两个远程仓库你的改动不会自动进原仓库。5.2 Pull Request从 Fork 到被合并的完整路径想给一个开源项目贡献代码标准流程是这样的在平台上 Fork 目标仓库得到你自己的副本。git clone你的副本到本地。建一个描述性的分支比如fix-null-pointer-in-parser。在这个分支上改代码、提交。git push到你的 Fork 仓库。在平台上从你的分支向原仓库发起 Pull RequestPR。项目维护者审查你的改动可能提意见让你改改完再 pushPR 会自动更新。通过后由维护者合并进原仓库。这个流程里最容易忽略的是第 3 步——直接在 Fork 的主分支上改。这样做的坏处是如果维护者让你改或者你想同时做两件事主分支会变得很乱。养成“一个 PR 一个分支”的习惯是参与开源的基本素养。提示发起 PR 前先看看项目有没有贡献指南通常叫 CONTRIBUTING.md里面会写代码风格、提交信息格式、测试要求。照着做能大幅提高被合并的概率。不看的后果往往是 PR 被晾着维护者一句“请先阅读贡献指南”就把你打发了。5.3 Issue不只是报 bug 的地方Issue 常被当成 bug 报告区其实它也是提需求、讨论方案、提问的地方。提 Issue 有个基本原则先搜再提。你遇到的问题很可能已经有人提过并有解决方案重复提只会增加维护者负担。搜索关键词用报错信息里的核心词比用大白话描述更容易命中。写 Issue 时把环境操作系统、版本号、复现步骤、期望结果、实际结果写清楚。能附最小复现代码就附。我见过太多“用不了求解决”这种 Issue维护者根本无从下手最后只能关闭。反过来信息完整的 Issue 往往很快得到回应因为别人一看就知道问题在哪。6. 新手最容易栽的几个坑与应对这一节集中讲我带新人时反复见到的错误每个都说清楚原因和正确做法你对照自查能省不少时间。6.1 提交了不该提交的文件最常见的是把target/编译产物、.idea/配置、甚至含密码的配置文件提交上去了。原因通常是先git add .一把梭没看status就提交。应对办法前面讲过.gitignore提前配好add前先status扫一眼。如果已经提交了用git rm --cached 文件名移除跟踪再提交历史里的旧记录如果含敏感信息那得用更复杂的手段清理所以防患于未然比事后补救重要得多。6.2 在错误的分支上改代码写着写着发现改错分支了改动还没提交。这时候别慌git stash能把当前改动暂存起来切到正确分支后git stash pop恢复。如果已经提交了可以用git cherry-pick 提交hash把那个提交摘到正确分支再在原分支上回退。这两个命令新手可以先记住stash这一招够应付大部分“改错地方”的场景。6.3 合并冲突处理到一半想放弃冲突改到一半发现搞乱了想回到合并前的状态执行git merge --abort一切回到 merge 之前。这个命令是救命稻草记住它。同理rebase中途想放弃用git rebase --abort。遇到烂摊子先想“有没有 abort”比硬着头皮改安全。6.4 push 被拒绝远程有你没有的提交push时报“rejected”通常是因为远程分支有你本地没有的新提交别人推过或者你在平台上直接改过文件。正确做法是先git pull把远程的拉下来合并解决可能的冲突再push。千万别上来就push -f强推那会覆盖别人的提交是协作中的大忌。强推只在自己独占的分支、且明确知道后果时才能用。现象大概率原因正确处理push rejected远程有新提交先 pull 合并再 push忽略规则不生效文件已被跟踪git rm --cached后提交提交记录认不出作者邮箱与平台账号不一致改 config 邮箱冲突标记进了代码合并后没删标记搜清理7. 把 Git 用成肌肉记忆的日常习惯工具这东西看十篇教程不如自己天天用。我给几个能让你快速形成肌肉记忆的建议都是我自己实践下来有效的。第一小步提交。每完成一个能说清楚的小改动就提交一次别攒一大坨再提交。小提交的好处是历史清晰、回滚精准、冲突范围小。判断标准很简单你能用一句话准确描述这次提交干了什么就可以提交了。第二提交前必看 status 和 diff。git status看有哪些文件动了git diff --staged看具体改了什么。这个习惯能拦住绝大多数“误提交”。多花十秒省得以后清理历史。第三分支名和提交信息写人话。分支名用fix-xxx、feature-xxx这种能看出意图的格式提交信息写清楚“为什么改”而不只是“改了什么”。这些文字是写给未来的自己和协作者看的值得认真对待。第四每天开工先 pull收工前 push。养成同步习惯能避免本地和远程越差越远最后合并成大麻烦。当然前提是当天的工作到了一个可提交的状态半成品别硬推。第五遇到不懂的命令先查再敲。Git 有些命令破坏性很强比如reset --hard、clean -fd敲之前确认它到底干什么。我见过有人reset --hard把一天的工作全清了因为没搞懂它会丢弃工作区改动。不确定的时候先git stash备份一下再操作多一层保险。这套东西说到底就一句话Git 不是考试科目是每天要用的工具。你不需要背下所有命令但要把“提交、查看、分支、同步”这几个高频动作练到不用想就能敲出来。剩下的边用边查用着用着就全通了。我自己到现在也经常查某个参数怎么拼这不丢人把活干对才重要。