1. 安装与初始化别急着敲命令说到Git很多新手第一反应是“装个软件而已下一步下一步就完事了”然后打开终端直接git commit结果要么报Author identity unknown要么发现提交到了错误的仓库里。这些问题我在刚接触Git时全踩过一遍后来把安装和初始化这一步认真捋清楚后面所有操作都顺了很多。先聊安装。Windows用户最省心的方式是去Git官网下载安装包一路默认选项装完就好。但有两点值得手动确认一是安装路径尽量不要带中文和空格避免后续某些IDE或脚本解析路径出问题二是在“Select Components”界面勾选“Git Bash Here”和“Git GUI Here”这样右键菜单里就能直接打开Git Bash日常使用非常方便。安装完成后在任意目录右键选择“Git Bash Here”弹出的黑色终端里输入git --version如果显示类似git version 2.x.x.windows.x说明安装成功。这里插一句Git Bash的定位。它本质上是一个模拟Linux环境的终端工具专门给Windows用户提供一个接近Unix的命令行体验。很多教程里的命令比如ls、touch、cat在Windows自带的CMD里是跑不通的但在Git Bash里全部可用。所以我个人的建议是从第一天起就只用Git Bash别碰CMD这样能少踩很多“命令不存在”的坑。安装完成后的第二步是设置身份信息。很多初学者跳过了这一步等到第一次提交时才被Git强制要求然后胡乱填一个名字和邮箱结果这些信息被永久记录在提交历史里后期想改非常麻烦。正确的做法是提前设置全局身份git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有两个点需要注意。第一user.name和user.email会写入提交记录的元数据里别人在GitHub或GitLab上看到你的提交显示的就是这两个信息所以建议使用真实姓名或常用的拼音ID邮箱最好用注册代码托管平台时使用的那个。第二如果你在某个项目里有单独的身份需求比如公司项目用公司邮箱个人项目用个人邮箱可以在具体仓库目录下运行不带--global的版本这样该项目的身份配置会覆盖全局配置。配置完之后用git config --list查看所有配置项确认无误后再装一个顺手的小工具——配置默认分支名。Git新版本默认分支是main但很多老项目和教科书还在用master。为了避免每次建仓库时手动git branch -m main我习惯提前设置git config --global init.defaultBranch main这样git init时初始分支直接就是main省得后面统一分支名时麻烦。到这里Git的安装和初始化才算真正做完接下来才谈得上“用起来”。2. 日常提交三板斧add、commit、statusGit的学习曲线陡很大原因是它引入了一套“暂存区”的概念。很多新手第一次提交代码时会直接执行git commit -m xxx然后诧异地发现终端提示nothing to commit原因就是没有先把文件加入暂存区。可以把Git的三块区域理解成一个快递发货流程工作区是你家里堆着的货物文件暂存区是打包区你可以反复往打包区里塞东西、拿出去版本库是已经发出去的快递历史记录。只有把货物从家里搬到打包区git add再从打包区确认发货git commit这个流程才算走完。最基本的提交流程是git status # 查看当前状态 git add 文件名 # 把指定文件放入暂存区 git add . # 把当前目录下所有改动放入暂存区 git commit -m 提交说明三个命令各有各的用途。git status是最应该高频使用的命令它能看到哪些文件被修改、哪些已进入暂存区、哪些还未被跟踪。我见过不少人提交后才发现把不该提交的文件比如.env配置文件、日志文件、IDE配置目录一并推上去了就是因为没有先在git status里检查一遍。git add .虽然方便但危险也大。它会把当前目录下所有未忽略的文件都加进暂存区如果你没有配置好.gitignore很容易把node_modules、target这类依赖目录或构建产物提交进去。提交了一大堆垃圾文件后回退又麻烦仓库体积也被撑大。我的习惯是先配置好.gitignore再使用git add .。.gitignore的语法很简单核心就几条node_modules/ target/ *.log .env .idea/ .vscode/每行一个规则目录名加斜杠表示忽略整个目录*是通配符。如果你不确定某个文件该不该忽略可以在网上搜对应语言的.gitignore模板GitHub官方也提供了各主流语言的模板仓库直接复制改一改就行。提交说明的规范也很重要。git commit -m 修改了一些东西这种写法过两周你自己回看历史都不知道当时干了什么。业界比较通用的是“动词开头具体内容”的形式比如fix: 修复登录接口超时问题、feat: 新增用户导出功能。如果团队有统一的提交规范比如Conventional Commits就按团队的来如果没有至少做到“别人看一眼就知道这次提交做了什么”。实际开发中还有个高频操作刚提交完发现注释写错了或者漏了一个文件。这时候git commit --amend就派上用场了。它的作用是修改最近一次提交不会产生新的提交节点而是把新改动合并进上一个提交里。用法分两种情况如果只是改提交注释git commit --amend -m 修正后的提交说明如果漏了文件先把漏掉的文件加进暂存区再执行amendgit add 漏掉的文件 git commit --amend --no-edit--no-edit表示沿用原来的提交说明不再打开编辑器。这里要特别警告一点git commit --amend只适用于还没有推送push到远程仓库的提交。如果你已经push了再amend会导致本地和远程的提交历史不一致下次push时会被拒绝强行pushgit push --force则可能覆盖队友的提交引发灾难。所以我的原则是push之前随便改push之后尽量别再碰历史。3. 撤销与回退reset、revert与checkout的边界如果说提交是Git最常用的功能那么撤销操作就是Git最容易让人迷路的区域。热词里出现了“idea git 需要撤销已经提交到远程分支的代码”这正好是撤销操作里场景最复杂的一种——已经推到远程的提交怎么撤撤了之后怎么让远端同步。先理清楚三个命令的分工。git checkout新版用git restore用于丢弃工作区的修改、切换分支或恢复某个文件git reset用于回退提交历史改变指针位置git revert则用一次新的提交来“反向操作”某次历史提交。三者的适用场景完全不同。场景一改动还在工作区/暂存区想放弃。git restore 文件名 # 丢弃工作区改动 git restore --staged 文件名 # 把文件从暂存区退回工作区这两个命令操作的是“未提交”状态非常安全不会动任何历史记录。场景二提交了但还没push想撤销提交。这时候git reset是首选。它有三种模式--soft、--mixed默认、--hard。区别在于reset之后工作区和暂存区的状态--soft只移动HEAD所有改动留在暂存区你可以重新git commit。--mixed移动HEAD改动回到工作区需要重新git add。--hard移动HEAD同时丢弃所有改动工作区直接变干净。举个例子你连续提交了两次想把最近一次撤销但保留代码改动就执行git reset --soft HEAD~1此时代码还在暂存区直接修改后重新提交即可。如果不仅想撤销提交连代码改动都不要了就用git reset --hard HEAD~1。这里提醒一句--hard模式一旦执行丢弃的改动无法通过Git找回除非你有IDE的本地历史所以执行前务必确认没有有价值的内容。场景三已经push到远程分支想撤销。这是最麻烦的情况因为直接git reset后本地和远程就脱节了。这里要看“撤销”的真实目的是什么。如果目的是“让远程分支的代码回退到某个历史版本”推荐做法是git revert而不是git reset --hard force push。git revert会生成一个新的提交这个提交的内容是对某次历史提交的“反向修改”比如你之前提交了“新增A文件”revert这个提交后Git会自动生成一个“删除A文件”的提交。它的好处是完全不动历史不需要force push远程和本地都能保持同步团队协作时最安全。git revert HEAD --no-edit如果commit注释写错了也可以用revert吗不建议这种情况优先用amend或者直接重新提交revert会多出来一条无意义的反向提交记录反而弄脏了历史。那什么时候需要用git reset --hard去处理远程分支我的经验是仅限于你自己独占的分支且在无人协作的时间窗口内。比如你单独维护的feature分支推送后发现提交内容有问题想彻底改变历史这时可以git reset --hard 目标commit git push --force-with-lease注意我用的是--force-with-lease而不是裸的--force。前者会在推送前检查远程分支是否被其他人更新过如果远端有本地不知道的新提交它会拒绝推送防止把别人的提交冲掉。这个参数是我给所有需要force push场景的默认推荐。4. 分支管理合并、切换与团队协作规范分支是Git区分于SVN这类集中式版本控制系统的灵魂功能但也恰恰是很多新手最不适应的部分。热词里“git分支合并”“git分支管理规范”“我在master上写的代码怎样剪切到dev上”这些需求全是围绕分支操作展开的。先解决“在master上写的代码想挪到dev分支”这个高频问题。核心思路是分支只是一个指针代码改动不会因为切换分支就消失。假设你在master上提交了改动现在想把这个提交挪到dev分支做法很简单git checkout dev # 切到dev分支 git cherry-pick commit号 # 把指定提交“摘”过来cherry-pick的作用是把某次提交原样复制到当前分支上。如果只想把工作区未提交的改动带到dev分支更简单的方法是先在master上git stash暂存改动切到dev后git stash pop改动就会出现在dev的工作区里。再看分支合并。最常用的两种方式是merge和rebase它们都能把两个分支的代码聚到一起但产生的结果截然不同。git merge会创建一个“合并提交”保留两条分支的分叉历史这种方式对理解“代码从哪里来”最直观但历史会显得杂乱尤其是多人长期并行开发时合并提交一多git log图形就像地铁线路图一样复杂。git rebase则会把当前分支的提交“移植”到目标分支的最新节点之后历史变成一条直线。它的优点是整洁缺点是你等于改写了本地提交的时间顺序如果操作失误容易导致提交丢失或冲突反复出现。我个人的习惯是个人feature分支用rebase保持整洁公共分支如main、dev只用merge保证安全。分支管理规范方面这几年团队实践下来比较成熟的一套结构是main/master分支始终处于可发布状态禁止直接提交代码。develop分支日常开发集成分支功能分支合并到这里。feature分支从develop切出命名类似feature/用户登录、fix/修复订单超时开发完成后合并回develop。release分支从develop切出做发布前的修复和准备发布后合并进main和develop。这套规范的好处是边界清晰开发者的日常操作几乎都在feature分支上不会误碰保护分支。加上代码托管平台的“分支保护规则”强制main和develop分支不允许直接push必须通过Merge Request/Pull Request合并团队协作的质量就有了基本保障。我见过不少小团队甚至有些大公司内部的边缘项目根本没有分支规范所有人都在master上直接提交几天后master就变成了一锅粥发布时根本不知道哪些代码是已经验证过的。所以我的建议是哪怕你只是一个人开发也要养成“主分支保护、功能分支开发”的习惯这是Git使用中性价比最高的自律。5. 远程仓库协作SSH配置、Token与免密登录本地玩得再溜最终还是要和远程仓库交互。热词里“ssh认证失败 git”“git配置gitee密钥”“git免密”“git设置代码库token”这些搜索说明大量用户的卡点在远程连接环节。这个环节的坑确实多但底层的逻辑其实很简单。远程仓库的认证方式就两大类HTTPS和SSH。HTTPS方式下每次push/pull都可能要求输入用户名和密码新版GitHub和Gitee则要求使用个人访问令牌Personal Access Token替代密码。SSH方式则是通过密钥对完成身份认证配置好之后可以实现免密操作这也是所有老手推荐的方式。SSH密钥配置的正确步骤如下第一步生成密钥对。在Git Bash里执行ssh-keygen -t rsa -b 4096 -C 你的邮箱或备注一路回车到底不设密码短语passphrase这样之后每次连接不会要求额外输入。生成的文件默认在~/.ssh/目录下id_rsa是私钥id_rsa.pub是公钥。第二步查看公钥内容并复制cat ~/.ssh/id_rsa.pub复制出来的是一长串ssh-rsa AAAA...开头的文本。第三步把公钥配置到代码托管平台。以Gitee为例登录后在“头像 → 设置 → SSH公钥”页面粘贴保存即可。GitHub则是在“Settings → SSH and GPG keys → New SSH key”里操作。这里有个细节一台电脑只需要配置一次公钥后续所有仓库共用。换电脑或重装系统后重新生成密钥再添加一次即可。第四步验证连接是否成功ssh -T gitgitee.com如果提示Hi xxx! Youve successfully authenticatedGitee或Hi xxx! Youve successfully authenticated, but GitHub does not provide shell accessGitHub就说明SSH认证已经通了。SSH认证失败是排查热点我遇到过的情况基本可以归纳为四类症状原因解决办法Permission denied (publickey)公钥未正确添加到平台检查cat ~/.ssh/id_rsa.pub内容是否和平台一致Host key verification failed首次连接时没确认指纹执行ssh-keyscan github.com ~/.ssh/known_hosts或删除known_hosts重新连接有多个密钥文件Git选错了密钥默认使用id_rsa如果你用的是其他文件名在~/.ssh/config里按主机指定IdentityFile公司内网限制22端口网络层拦截SSH连接改用HTTPS方式或配置SSH走443端口第四类情况在某些网络环境下很常见GitHub官方就支持在443端口跑SSH连接。方法是在~/.ssh/config里加一段配置Host github.com Hostname ssh.github.com Port 443 User git配置免密除了SSH这条路HTTPSToken方式也同样奏效。现在GitHub和Gitee都支持“缓存凭据”第一次输入用户名加Token后Git会把这些信息缓存起来后续操作不再要求输入。Windows下Git自带的git-credential-manager会弹出一个对话框让你输入勾选“记住”即可。这种方式不用碰密钥文件对新手更友好。我个人的经验是如果日常只在一两台电脑上开发SSH一劳永逸如果经常换机器、或用别人的电脑临时改代码Token缓存方式更方便。6. 进阶操作submodule子模块与目录安全问题先聊git submodule。这个功能的适用场景很明确一个仓库需要依赖另一个仓库的特定版本。比如你有一个公共组件库多个项目都在用你就可以在主项目里把组件仓库挂为子模块。当公共组件更新时主项目可以显式地选择是否升级到新版本避免公共库一改所有项目都被动受影响。添加子模块的常用命令git submodule add 仓库地址 本地路径执行后仓库里会出现一个.gitmodules文件内容记录了子模块的映射关系。别人克隆你的主项目时需要先执行两个命令才能把子模块代码拉下来git submodule init git submodule updateGit新版本还提供了一个更直接的命令git clone --recurse-submodules 仓库地址一步到位。子模块用起来有一个很困扰的点子模块本身就像半个独立的仓库。在父项目里git submodule update会把子模块切到对应提交但如果子模块内部有未提交的改动父项目会显示子模块是“脏的”。处理方式是在子模块目录里正常提交推送然后在父项目里再提交一次更新子模块指针的记录。关于git目录泄露这个话题它指向的是一个不同的方向——安全问题。所谓Git目录泄露是指网站或其他应用把.git目录暴露在公开访问的路径下导致攻击者可以通过下载.git目录中的对象文件逆向还原出完整的源码、配置信息甚至敏感密钥。这类漏洞在渗透测试中属于常规检查项现实中也有不少因为疏忽导致源码泄露的案例。这里我必须把安全这根弦绷紧开发者在部署项目时务必确认.git目录不会被Web服务器访问。常见的防护手段包括部署时只拷贝业务代码、在Nginx/Apache配置中禁止访问.git路径、通过CI/CD流水线从仓库拉取代码后只构建产物不复制元数据。对于个人学习项目来说Git本地仓库放在开发机上是完全没问题的但一旦涉及对外部署就要把.git目录当作敏感资产对待。Git在目录安全方面还涉及到另一个常见问题仓库里不该提交的文件误提交了怎么办。除了前面说的配置.gitignore防患于未然如果敏感信息已经提交并且推送到远程应该立即做三件事一是修改或吊销泄露的密钥比如API Key、密码二是用git rm --cached 文件名把文件从版本控制中移除保留本地文件三是推送到远程后还要在托管平台的历史记录里清理该文件因为普通删除并不会把历史中的文件删掉。GitHub官方提供了相关文档“Remove sensitive data from a repository”可以参考。7. 高频坑点排查从open /dev/null到GUI工具选型回到那些让人抓狂的报错。我在整理笔记时专门记录了一批高频问题这里挑两个有代表性的展开说。报错一git open /dev/null or dup failed: no such file or directory。这个错误我在Windows环境里遇到过触发场景通常是Git Bash在启动或执行某些命令时报的。排查下来主要有两种原因一是安全软件杀毒、终端监控类拦截了Git调用虚拟设备文件的操作二是Git Bash的环境变量或临时目录设置异常。建议优先检查杀毒软件的隔离日志把Git相关目录加入白名单其次检查系统临时目录%TEMP%是否可写。如果都正常可以尝试以管理员身份运行Git Bash或重装Git并勾选“Enable symbolic links”选项。报错二ssh: connect to host github.com port 22: Connection timed out。这个我之前在一次网络环境受限的场合遇到过排查思路是先确认是不是网络问题——用ssh -T gitgithub.com -p 443测试443端口是否可用或者用浏览器访问github.com试试。如果443能通就按前面说的方法配置SSH走443端口。如果还是不通改用HTTPSToken方式连接仓库也是一个稳定可靠的替代方案。IDE与Git的配合问题热词里也出现了“idea修改git提交的账户”“idea怎么安装git”“idea创建新项目拉取git”等这里一并说清楚。IntelliJ IDEA内置了Git支持它不是独立的Git客户端而是调用系统环境变量PATH中的Git命令。所以前提是你在机器上装好了Git并在IDEA的Settings → Version Control → Git里指定了正确的路径。Windows下通常是C:\Program Files\Git\bin\git.exe。IDEA修改提交账户本质上就是改Git的user.name和user.email配置在Settings → Version Control → Git里可以设置全局的还是当前项目的身份也可以直接改仓库所在目录的.git/config文件。用IDEA从远程拉取新项目的方式很简单File → New → Project from Version Control粘贴仓库地址选择目录即可。IDEA会自动识别仓库类型并拉取代码。整个过程中最需要留意的还是身份配置——很多人在IDEA里提交时发现提交者变成了一个不认识的名字就是因为全局Git配置没有设置IDEA用了系统默认值。Git GUI工具的选择上我个人的建议分三档日常轻度使用、只提交代码不搞复杂操作的新手直接在IDE里用内置Git即可如果命令行不熟又想可视化管理分支Git自带的Git GUI和GitKraken、Sourcetree这类工具都不错如果追求效率和可控性趁早把Git Bash命令行练熟练。工具只是外壳命令背后的原理才是真正的能力热词里的“git小乌龟”指的是TortoiseGit它是Windows资源管理器集成型GUI很多老开发者习惯用它但它的功能上限明显低于命令行复杂操作交互式rebase、cherry-pick多个提交还是得回终端。最后放一个我反复踩坑后形成的日常操作清单动任何“危险命令”前先git status看清楚当前状态。不确定的改动先git stash保存不要直接git checkout .丢代码。提交信息包含“改了什么为什么改”一句话能说清就别堆两行。push之前检查git log --oneline -3确认提交历史是你想要的。发生冲突时别急着删别人的代码先git diff看清楚双方改动再手动合并。.gitignore放在仓库根目录创建仓库时就配好不要等提交后再补。Git这个东西入门门槛不高但真正用得顺手需要的是对几个核心概念的透彻理解——提交、分支、远程、撤销、合并。把这些概念串起来配合高频实操两周左右就能形成肌肉记忆。这篇文章里的每一条命令都来自我个人项目的实际记录踩过的坑也都标注了原因和回避方式希望你看完不只是收藏而是打开终端亲手敲一遍。毕竟Git这东西光看不练永远都叫“好像会了”。