1. 开篇为什么每个开发者都得过Git这道坎Git 这个东西只要你碰代码早晚绕不开。无论是个人项目备份还是团队协作开发Git 几乎是现代软件开发的默认基础设施。我看到很多新手一开始觉得 Git 难命令多、概念杂一不小心就把仓库搞乱了。但说实话Git 的核心逻辑就那么几条一旦你理解了提交、分支、合并、远程这几个基本概念剩下的就是熟练度问题。这篇文章我尽量从一个实际使用的角度来写不堆概念直接讲怎么安装、怎么配置、日常怎么用、出了问题怎么排查。内容会覆盖 Windows 和 macOS 两种系统下的安装方式Git Bash 的常用操作SSH 密钥配置以及提交代码、拉取代码、分支管理、撤销修改、解决冲突等高频场景。最后还会整理一些我实际踩过的坑和排查方法希望能帮你省点时间。如果说有什么要提前说的那就是Git 的操作是不可逆性极强的一个工具很多命令一旦执行就没有后悔药所以养成提交前检查、删除前确认的习惯比会背命令重要得多。2. 环境准备从安装到第一行 git 指令2.1 Windows 系统Git 安装与环境变量配置Windows 下安装 Git 通常有两种选择一种是直接用 Git for Windows 的安装包另一种是通过包管理器比如 winget 或者 Scoop。我平时推荐直接下载安装包因为安装过程可以顺便把环境变量、换行符转换、SSH 客户端这些细节一并处理好。从 Git 官网下载对应系统的安装包后一路 Next 即可。这里有几个选项需要注意安装路径建议保持默认不要装到带空格的文件夹里后续配置 SSH 密钥时会省很多麻烦。在选择默认编辑器时如果你装了 VS Code就选 “Use Visual Studio Code as Git’s default editor”如果没装Keep NotePad 或者 Vim 都行反正不太影响日常使用。调整 PATH 环境变量时务必选择 “Git from the command line and also from 3rd-party software”这一步决定了你之后能不能在 CMD、PowerShell 或者 IDEA、VS Code 里直接使用 git 指令。换行符处理那一项建议选择 “Checkout Windows-style, commit Unix-style line endings”这是最稳妥的跨平台方案。安装完成后打开 CMD 或 PowerShell输入git --version如果输出了类似git version 2.40.0.windows.1的信息说明安装成功了。如果没有识别大概率是环境变量没生效注销或重启后再试或者手动检查系统环境变量的 Path 里有没有 Git 的 bin 目录。macOS 用户就简单多了安装 Xcode Command Line Tools 时会自动带上 Git也可以用 Homebrew 执行brew install git。这种差异没有必要纠结安装好了能跑第一条命令就行。2.2 Git BashWindows 下最好用的终端入口Git for Windows 装好后右键菜单里会出现一个 “Git Bash Here” 的选项。这个东西本质是一个跑在 Windows 上的模拟 Unix 终端的程序内置了常见的 Linux 命令ls、cd、cat、grep 等加上 Git 的命令集。我强烈建议 Windows 用户在学 Git 的阶段全程用 Git Bash不要用 CMD。原因有两个Git Bash 支持 Linux 风格的路径和命令比如~代表用户目录很多教程里的命令直接复制过来就能用。CMD 里的引号、空格、中文路径处理起来非常别扭而 Git Bash 几乎不会在这些地方卡壳。打开 Git Bash 后可以用pwd查看当前目录用cd切换目录用mkdir创建文件夹。这些命令和 Git 配合起来操作起来才顺手。2.3 TortoiseGit小乌龟不想记命令的人的图形化方案热词里有个“git小乌龟”指的就是 TortoiseGit。这是一个 Windows 下的 Git 图形客户端安装后会在文件夹右键菜单里显示各种 Git 操作选项比如 Commit、Pull、Push、Switch 等。TortoiseGit 适合不想频繁敲命令的用户尤其是纯前端或文档协作类的项目。我见过不少产品经理、测试同学用它来提交文档和配置文件完全不碰命令行也跑得通。不过需要注意TortoiseGit 只是一个 GUI 外壳底层还是要调用 Git 和 SSH 客户端所以安装顺序应该是先装 Git for Windows再装 TortoiseGit。如果打开仓库时报错说没找到 git.exe多半是安装顺序反了或者在 TortoiseGit 的设置里指定了错误的 Git 路径。2.4 全局配置姓名、邮箱、换行符和常用别名安装完 Git 之后的第一件事是配置用户信息。这一步很重要因为每次 commit 都会把用户名和邮箱写进提交记录里如果你想在 GitHub、Gitee 上正确显示提交者身份必须让这里的邮箱和平台账号一致。git config --global user.name 你的名字 git config --global user.email 你的邮箱可以用git config --list查看所有全局配置确认是否生效。如果你之前配过错误的邮箱别提多尴尬了提交记录里到处是你的“匿名”身份改起来还挺麻烦。除了用户名邮箱我还会顺手配两个东西。一个是默认分支名现在新建仓库默认分支很多还是master但新项目用main更符合趋势git config --global init.defaultBranch main还有一个是设置 pull 的默认行为为 rebase这样拉取远端更新时会尽量用变基而不是产生多余的合并提交历史记录更线性。这项不是必须的但对你养成清晰提交历史的习惯帮助很大git config --global pull.rebase true3. 核心概念与初始化理解仓库是怎么转起来的3.1 工作区、暂存区、版本库的关系Git 最大的门槛不是命令多而是三个概念没理解清楚工作区Working Directory、暂存区Staging Area/Index、版本库Repository/Commit History。打个比方工作区就是你电脑上真实的文件夹你能看到的所有文件都在这里。暂存区像是一个“候机厅”你文件改了之后需要先git add把文件送进候机厅最后用git commit把这些文件打包成一个不可变的版本永久记录在版本库里。很多人卡在git add和git commit为什么要分两步直接用一条命令不行吗其实分两步的好处是让你可以对每一次提交做精细控制。比如你改了 5 个文件但其中 3 个是功能 A2 个是功能 B完全可以用两次git add 两次git commit生成两条干净的提交记录而不是混在一起一大坨。命令上很简单# 添加所有改动到暂存区 git add . # 提交到版本库 git commit -m 提交说明如果你想跳过 add直接提交所有已跟踪文件的改动可以用git commit -am 说明但注意这个命令会把已跟踪文件的改动全部提交不会包含新创建的文件所以新文件还是得先 add。3.2 初始化仓库与 .gitignore新项目想用 Git 管理执行git init就会生成一个隐藏的.git目录这个目录里存放着这个仓库的所有历史信息、分支信息、配置信息。之后的所有版本记录都记录在这个.git里千万不能随便删除。初始化完成后下一步是写.gitignore文件。这个文件用来声明哪些文件或目录不应该被 Git 跟踪。常见的需要忽略的内容包括依赖文件夹node_modules/、vendor/这类的文件量巨大提交进去毫无意义编译产物dist/、build/、*.class、*.o环境配置文件.env、config.local.js里面往往有密钥和数据库地址IDE 和系统文件.idea/、.vscode/、.DS_Store、*.swp我见过最夸张的一个案例同事把node_modules提交到仓库里整个仓库瞬间多了十几万个小文件clone 一次要好几分钟而且每次 pull 都可能产生巨量冲突。这种事经历一次就终身难忘.gitignore的重要性了。3.3 Git 目录泄露一个常见的项目安全隐患热词里出现了“git目录泄露如何下载”这其实是一个安全相关的问题。所谓 Git 目录泄露指的是网站部署时把.git目录一并上传到了服务器导致任何人可以通过访问网站地址/.git/直接下载到整个项目的源码与历史版本。从防御角度说部署前一定要保证.git目录不在 Web 访问目录内或者用服务器配置禁止访问/.git开头的请求。这个信息虽然不属于日常操作但值得在团队里强调因为它往往是安全扫描中最常见的高危项之一。4. 日常高频操作每天都要打交道的 git 命令4.1 查看状态与提交历史我从实际使用的角度来说在 Git 的命令集里最高频的三个命令应该是git status、git log、git diff。git status用来查看当前工作区的状态哪些文件被修改了、哪些文件在暂存区、哪些文件没被跟踪一目了然。这个命令没有副作用随便敲、随便看养成先看状态再操作的肌肉记忆能避开大量低级错误。git log用来查看提交历史。默认输出会有点长用git log --oneline --graph --decorate --all可以输出一个简洁版的带分支关系的图表我几乎每次都这么敲。git diff用来查看工作区和暂存区之间的具体差异。如果想看某个具体文件的变化直接加上文件路径git diff 文件名这三个命令搭配使用能让你随时掌握自己的仓库处于什么状态尤其在冲突、合并、回滚等复杂操作之前先看一眼状态总没错。4.2 拉取远程代码到本地热词里有“git拉取远程代码到本地”这个场景太常用了。两种方式要分清第一次拿到一个项目的地址时用 clone 一次性把整个仓库拉下来git clone https://github.com/user/repo.git git clone gitgithub.com:user/repo.git第二种是仓库已经 clone 过了别人往远端推了新的提交你要把这些更新拉下来git pull这里提醒一点git pull实际上是git fetchgit merge的组合。如果你只执行git fetch远端更新只会下载到本地仓库的“远端跟踪分支”里你看不到代码变化但也不会影响当前工作内容。当你确认当前改动不会和远端的更新冲突时再执行git merge或git rebase。如果拉取时报local changes would be overwritten by merge说明你本地有未提交的修改且修改的文件和远端更新的文件重叠了。解决方式一般是# 临时保存本地改动 git stash # 拉取更新 git pull # 恢复本地改动 git stash pop4.3 提交信息规范与 amend 用法提交信息是项目的重要沟通渠道。我见过不少团队的提交信息全是“update”“fix”“改了点东西”时间一长根本不知道这个提交干了什么。推荐使用简单约定feat: 新增了某个功能fix: 修复了某个 bugdocs: 更新了文档refactor: 重构了代码不改变功能chore: 维护性工作依赖升级等热词里专门提到了git commit --amend这个命令的作用是修改上一次提交的信息或者把新的改动合并进上一次提交里。场景是这样的你刚提交了代码结果发现漏了一个文件没加或者提交信息里有个错别字不需要新建一个提交去“擦屁股”直接git add 漏掉的文件 git commit --amend执行后 Git 会打开编辑器让你修改提交说明。最方便的是直接用-m一次性搞定git commit --amend -m 修正后的提交信息这里有个大坑amend会改变提交的哈希值所以只适合修改“还没有推送到远端的提交”。如果已经 push 过了再 amend 会导致本地历史和远端不一致强行推送会被人骂轻则冲突重则重写共享历史非常不建议。4.4 撤销与回滚后悔药的选择题Git 之所以让人放心就是因为大多数操作都能“反悔”但反悔方式有好几种不少新手容易混。改乱了工作区的文件想恢复到上一次提交的状态git restore 文件名旧版本命令是git checkout -- 文件名。这个操作会丢弃当前工作区未暂存的修改不可逆。已经 add 到暂存区了想撤销暂存git restore --staged 文件名。这个操作不动工作区文件只是把文件移出暂存区。提交了但想撤销这个提交同时保留改动git reset --soft HEAD~1。相当于退回提交前改动还在暂存区。提交了且想把改动也丢了git reset --hard HEAD~1。这个非常危险会彻底删除提交和对应改动。想撤销一个已经 push 的提交更推荐用git revert HEAD。revert 会生成一个新的提交反向应用之前的改动不会破坏历史适合协作分支。用我的话总结一下reset是“回到过去”适合自己没推走的提交revert是“打补丁抵消”适合公共分支。这两个区别一定要记牢很多人就是在 push 后乱用 reset 导致同事拉下来的代码莫名其妙消失。5. 分支管理多线协作的核心5.1 创建分支与切换分支分支是 Git 最强大的设计之一。它允许你在同一份代码库上并行开发不同的功能互相之间不受干扰。想象一下你正在开发 A 功能突然线上有个 bug 马上要修复你只需要切换到master/main分支开一个hotfix分支去修 bug修完合并回主分支再切回 A 功能分支继续干活。这一切只需要几条命令# 创建并切换到新分支 git checkout -b feature/login # 或者使用新版命令 git switch -c feature/login # 列出所有分支 git branch -a # 切换分支 git checkout main日常开发中我不太建议直接在main分支上随便提交代码最好每次都基于main拉一个功能分支开发完合并回去再删除分支。这样 main 分支永远是干净、可发布的这个习惯在团队协作里可以有效减少冲突。5.2 合并分支与冲突处理合并不复杂复杂的是冲突。执行git merge 功能分支名如果两个分支改了同一个文件的同一行Git 没办法替你决定就会在文件里插入冲突标记 HEAD 当前分支的内容 被合并分支的内容 feature/login处理方式很简单手动编辑这个文件把冲突标记和多余的内容删掉留下你想要的结果然后git addgit commit完成合并。冲突并不可怕它反而是好事说明 Git 检测到了会导致逻辑不一致的修改。真正重要的是处理冲突后一定要仔细测试别因为表面上一行代码的取舍导致功能出问题。5.3 git worktree一个被低估的坑热词里出现了git worktree。这个命令是 Git 2.15 引入的功能允许你在同一份仓库下创建多个工作目录每个目录可以检出一个不同的分支。为什么需要它想象一个场景你在 feature 分支上开发到一半突然需要临时跳到另一个分支去修 bug但本地有未提交的修改又不想 stash。你可以git worktree add ../project-hotfix hotfix-branch这样会在上级目录开一个project-hotfix文件夹里面检出的是hotfix-branch可以完全并行操作。我之前在维护多个版本的场景下用 worktree 同时开 main、dev、release 三个目录切换起来极其流畅。用完后记得清理git worktree remove 目录路径 git worktree prune这个功能我在团队里推荐过第一批用的人不怎么多但上手后基本都回不去了。尤其是需要快速验证不同分支兼容性的时候比反复切换分支、腾挪工作区要高效太多。5.4 stash临时保存半成品git stash用来把当前工作区的未提交修改暂时保存起来使得工作区回到干净状态。等忙完别的事情再恢复。常用操作# 保存 git stash # 恢复最近一次 stash git stash pop # 查看 stash 列表 git stash list # 恢复指定 stash git stash apply stash{1}pop和apply的区别在于pop会恢复并删除这个 stash 记录apply只恢复不删除。我通常用pop除非同一个 stash 要在多个分支复用。有一个易错点如果你 stash 的修改涉及的文件和当前分支中的版本差异很大恢复时也可能冲突但概率不大处理好即可。6. 远程仓库与 SSH 密钥从本机到服务器的最后一公里6.1 clone、push、remote 的完整流程本地仓库和远程仓库的关联是通过 remote 配置实现的。clone 项目时远程仓库地址会被自动设置为origin这也是为什么你总能看到git push origin main这种写法。日常推送流程# 查看远程信息 git remote -v # 添加远程仓库 git remote add origin https://github.com/user/repo.git # 推送本地分支到远程 git push -u origin main-u参数的作用是建立本地分支和远程分支的关联第一次推送后后续直接git push即可不用每次写远程和分支名。推送时如果远端比本地领先Git 会拒绝推送提示git pull一下再推这是保护机制防止你覆盖别人提交的内容。遇到这种情况就老老实实 pull 再处理冲突不要加--force强推。强推真的会毁灭历史尤其多人协作时会导致别人的提交凭空消失。6.2 Gitee 与 GitHub 的 SSH 密钥配置SSH 密钥的作用是让你在推送代码时免去反复输用户名密码。从 Git 官网下载安装时一般会自带 OpenSSH所以 Windows 下配置 SSH 也很方便。先检查本机是否已有密钥ls ~/.ssh如果不存在id_rsa和id_rsa.pub文件就生成一个新的ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车即可也可以设置密码短语passphrase不过日常用建议留空省得每次操作都要输密码。生成后打开公钥文件cat ~/.ssh/id_rsa.pub把输出的内容复制然后登录 Gitee 或 GitHub在“设置 - SSH 公钥”里粘贴保存。之后测试连接# GitHub ssh -T gitgithub.com # Gitee ssh -T gitgitee.com如果看到Hi xxx! Youve successfully authenticated说明配置成功。此时 clone 远程仓库时记得用 SSH 格式的地址gitgithub.com:user/repo.git而不是 HTTPS 地址才能免密推送。6.3 配置 Gitee 密钥时遇到的经典报错我在配置 Gitee 密钥时最常见的一个报错是ssh: connect to host gitee.com port 22: Connection timed out。这种情况在国内网络环境里时有发生很多文章会建议换 443 端口来规避。修改方式是在~/.ssh/下新建或编辑config文件Host gitee.com HostName gitee.com Port 443 User git保存后再次执行ssh -T gitgitee.com。这个方案在多个云代码平台都适用本质上是利用 SSH over HTTPS 的方式绕过 22 端口的限制。我当年就靠这个解决了公司内网环境下的推送问题。6.4 Git 免密配置与账号密码保存如果你用的是 HTTPS 方式 clone 的仓库推送时会要求输入账号密码。Windows 下生成一次凭据后Git 一般会记住。但某些环境下没有启用凭据管理器每次都提示输密码很烦。可以执行git config --global credential.helper store这个方式会把凭据明文存储在用户目录的.git-credentials文件里。在自己的个人电脑上问题不大但在公用机器上不太安全建议用 Windows 自带的凭证管理器git config --global credential.helper manager另外还有一个技巧是在远程地址里直接内嵌账号信息比如git remote set-url origin https://用户名:密码github.com/user/repo.git这个方式我不推荐在真实项目中使用因为密码暴露在 bash 历史里一旦历史被翻出来就凉了。稳妥的做法还是用 SSH 密钥。7. 可视化与编辑器集成IDEA、VS Code 里的 Git 玩法7.1 IDEA 里的 Git 提交与推送热词里有“idea怎么用git提交代码”JetBrains 系 IDEIDEA、PyCharm、GoLand的 Git 集成做得很成熟。操作上改完代码后左侧的文件会变色蓝色表示修改绿色表示新增在项目根目录或文件上右键选Git - Commit Directory...左侧会列出所有改动文件勾选要提交的填写 Commit Message点 Commit 或 Commit and Push。比较顺手的功能是在提交面板里可以直接显示 diff点击文件即可查看改动详情。使用Ctrl K打开提交窗口Ctrl Shift K推送。底部工具栏的 “Log” 标签页可以看到分支图和提交记录非常直观。IDEA 里要设置好 Git 路径Settings - Version Control - Git。如果提示找不到 Git多半是环境变量没有生效或者你用了便携版 Git。7.2 VS Code 与 Git 插件VS Code 默认自带 Git 支持左侧的“源代码管理”图标可以直接看到改动文件列表。输入提交信息后点对勾图标提交然后点“同步更改”推送。如果想可视化分支和合并推荐安装 GitLens 或 Git Graph 插件。Git Graph 能直接绘制出分支走向图对理解整个仓库的演进历史特别有帮助。GitLens 则能显示每一行代码的最后修改者定位问题责任人的时候非常好用。我日常在写代码时会开着 Git Graph每次提交后看一眼分支图整个项目脉络清清楚楚。可视化工具和命令行并不冲突熟练后可以混用怎么高效怎么来。7.3 网上热传的git -c diff.mnemonicprefixfalse ...是什么热词里有一条很长的命令git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks这其实是某些 GUI 工具比如 SourceTree在底层调用 Git 时的参数配置。-c表示临时指定某个配置项不写入全局配置。core.quotepathfalse表示让 Git 在输出文件路径时不转义非 ASCII 字符解决中文文件名显示为\346\226\207\344\273\266这种乱码的问题。如果你在命令行里看到 Git 输出的中文路径是转义序列可以直接设置git config --global core.quotepath false这个配置对中文用户是刚需。至于diff.mnemonicprefix和--no-optional-locks日常手动操作基本用不到不用理会。8. 常见问题与排查实录8.1 fatal: not a git repository (or any of the parent directories): .git这个报错我之前刚入门时天天遇见。原因是当前目录根本不是 Git 仓库或者你的命令敲错了层级。解决方式执行ls -a看看有没有.git目录。如果没有说明当前文件夹还没初始化执行git init。如果有.git目录但命令仍然报错看看你是不是在.git目录内部执行了git branch之类的命令Git 不允许在这个目录里直接操作。还有一个隐蔽的场景用 Windows 的 CMD 时如果你在某个子目录下克隆了一个项目然后切到父目录执行 git 命令也会报这个错。解决方案就是先cd到对应仓库根目录下再操作。8.2 login failed. check api token or gitlab version这句话不是 Git 本身的报错而是某些 Git 桌面客户端或编辑器插件连接 GitLab 时的认证失败提示。常见原因有GitLab 账号没有正确配置 Access Token 或 API Token。个人访问令牌过期了。GitLab 默认可以为 token 设置过期时间。GitLab 版本过低新版 API 和旧版客户端不兼容。你在公司内网访问代理设置干扰了 API 请求。处理思路是先去 GitLab 个人设置里生成一个新的 token保证权限至少包含read_repository和write_repository。然后在客户端里重新填写。如果依然失败检查是否在 IDE 插件里填错了 GitLab 地址有些环境要用内部域名而不是外网入口。8.3 Git Bash 中文乱码问题Git 在 Windows 下显示中文文件名或提交信息时乱码原因基本都是编码问题。核心思路是让 Git 对所有输入输出都使用 UTF-8。核心配置git config --global core.quotepath false git config --global gui.encoding utf-8 git config --global i18n.commit.encoding utf-8 git config --global i18n.logoutputencoding utf-8如果提交信息在 Git Bash 里显示正常但 IDEA 里乱码那就要去检查 IDEA 的文件编码设置统一改成 UTF-8。8.4 提交错分支把 A 分支的改动提交到 B 分支了这种问题几乎每个人都会遇到。处理方式我记得特别清楚。假设你本想在feature/login开发结果在main分支上改了文件并提交了。要修正的做法是# 回退提交但保留改动 git reset --soft HEAD~1 # 把改动 stash 起来 git stash # 切到正确的分支 git checkout feature/login # 恢复改动 git stash pop # 重新提交 git add . git commit -m feat: 登录功能这个流程的核心是reset --soft加stash整个过程不会丢失任何代码改动。我就是靠这个流程帮团队伙伴抢救过好几个“提交串台”的现场。8.5 误删分支后的恢复分支被误删通常还有救。git branch -D删除分支后分支最后一次提交的哈希仍然存在。如果你还记得大概的提交信息可以用# 查看所有历史提交包括被删分支的 git reflog show --all # 通过提交哈希重新创建分支 git checkout -b 分支名 提交哈希reflog是 Git 的“操作日志”记录了你本机执行过的几乎每一次 HEAD 移动。它不等于提交历史但能帮你找回大量“以为丢了”的分支和提交。我在一次误删分支后就是靠 reflog 找回了一个带大量工作成果的分支从那以后我对 reflog 一直很敬畏。9. 实操心得与个人经验分享按我自己的使用习惯Git 最有价值的地方不是它能记多少版本而是它给了我一种“随便改、不怕乱”的安全感。文件改废了可以回滚分支切错了可以恢复提交写错了可以改造。这种安全感是写代码时极大的心理支撑。不过我也走过弯路。买了课程、背了命令表真正入门其实是从“强制自己把 IDEA 里的操作换成命令行”开始的。用命令行不是装而是逼着自己理解每一步在干什么。等你理解之后再回到 IDEA、VS Code 的图形界面你会发现所有按钮都变得透明了你知道它背后执行的是一条什么命令也知道它操作的是工作区还是暂存区。最后分享一个小技巧如果你刚接手一个项目别急着改代码先用git log --oneline --graph --all看一遍分支结构和提交历史再跑到git reflog里看一眼近期的操作记录基本能猜出团队协作的节奏和习惯。这种“先看历史再动笔”的做事方式平时看起来不起眼关键时刻能帮你避掉大坑。
Git从入门到实战：安装配置、常用命令与问题排查
1. 开篇为什么每个开发者都得过Git这道坎Git 这个东西只要你碰代码早晚绕不开。无论是个人项目备份还是团队协作开发Git 几乎是现代软件开发的默认基础设施。我看到很多新手一开始觉得 Git 难命令多、概念杂一不小心就把仓库搞乱了。但说实话Git 的核心逻辑就那么几条一旦你理解了提交、分支、合并、远程这几个基本概念剩下的就是熟练度问题。这篇文章我尽量从一个实际使用的角度来写不堆概念直接讲怎么安装、怎么配置、日常怎么用、出了问题怎么排查。内容会覆盖 Windows 和 macOS 两种系统下的安装方式Git Bash 的常用操作SSH 密钥配置以及提交代码、拉取代码、分支管理、撤销修改、解决冲突等高频场景。最后还会整理一些我实际踩过的坑和排查方法希望能帮你省点时间。如果说有什么要提前说的那就是Git 的操作是不可逆性极强的一个工具很多命令一旦执行就没有后悔药所以养成提交前检查、删除前确认的习惯比会背命令重要得多。2. 环境准备从安装到第一行 git 指令2.1 Windows 系统Git 安装与环境变量配置Windows 下安装 Git 通常有两种选择一种是直接用 Git for Windows 的安装包另一种是通过包管理器比如 winget 或者 Scoop。我平时推荐直接下载安装包因为安装过程可以顺便把环境变量、换行符转换、SSH 客户端这些细节一并处理好。从 Git 官网下载对应系统的安装包后一路 Next 即可。这里有几个选项需要注意安装路径建议保持默认不要装到带空格的文件夹里后续配置 SSH 密钥时会省很多麻烦。在选择默认编辑器时如果你装了 VS Code就选 “Use Visual Studio Code as Git’s default editor”如果没装Keep NotePad 或者 Vim 都行反正不太影响日常使用。调整 PATH 环境变量时务必选择 “Git from the command line and also from 3rd-party software”这一步决定了你之后能不能在 CMD、PowerShell 或者 IDEA、VS Code 里直接使用 git 指令。换行符处理那一项建议选择 “Checkout Windows-style, commit Unix-style line endings”这是最稳妥的跨平台方案。安装完成后打开 CMD 或 PowerShell输入git --version如果输出了类似git version 2.40.0.windows.1的信息说明安装成功了。如果没有识别大概率是环境变量没生效注销或重启后再试或者手动检查系统环境变量的 Path 里有没有 Git 的 bin 目录。macOS 用户就简单多了安装 Xcode Command Line Tools 时会自动带上 Git也可以用 Homebrew 执行brew install git。这种差异没有必要纠结安装好了能跑第一条命令就行。2.2 Git BashWindows 下最好用的终端入口Git for Windows 装好后右键菜单里会出现一个 “Git Bash Here” 的选项。这个东西本质是一个跑在 Windows 上的模拟 Unix 终端的程序内置了常见的 Linux 命令ls、cd、cat、grep 等加上 Git 的命令集。我强烈建议 Windows 用户在学 Git 的阶段全程用 Git Bash不要用 CMD。原因有两个Git Bash 支持 Linux 风格的路径和命令比如~代表用户目录很多教程里的命令直接复制过来就能用。CMD 里的引号、空格、中文路径处理起来非常别扭而 Git Bash 几乎不会在这些地方卡壳。打开 Git Bash 后可以用pwd查看当前目录用cd切换目录用mkdir创建文件夹。这些命令和 Git 配合起来操作起来才顺手。2.3 TortoiseGit小乌龟不想记命令的人的图形化方案热词里有个“git小乌龟”指的就是 TortoiseGit。这是一个 Windows 下的 Git 图形客户端安装后会在文件夹右键菜单里显示各种 Git 操作选项比如 Commit、Pull、Push、Switch 等。TortoiseGit 适合不想频繁敲命令的用户尤其是纯前端或文档协作类的项目。我见过不少产品经理、测试同学用它来提交文档和配置文件完全不碰命令行也跑得通。不过需要注意TortoiseGit 只是一个 GUI 外壳底层还是要调用 Git 和 SSH 客户端所以安装顺序应该是先装 Git for Windows再装 TortoiseGit。如果打开仓库时报错说没找到 git.exe多半是安装顺序反了或者在 TortoiseGit 的设置里指定了错误的 Git 路径。2.4 全局配置姓名、邮箱、换行符和常用别名安装完 Git 之后的第一件事是配置用户信息。这一步很重要因为每次 commit 都会把用户名和邮箱写进提交记录里如果你想在 GitHub、Gitee 上正确显示提交者身份必须让这里的邮箱和平台账号一致。git config --global user.name 你的名字 git config --global user.email 你的邮箱可以用git config --list查看所有全局配置确认是否生效。如果你之前配过错误的邮箱别提多尴尬了提交记录里到处是你的“匿名”身份改起来还挺麻烦。除了用户名邮箱我还会顺手配两个东西。一个是默认分支名现在新建仓库默认分支很多还是master但新项目用main更符合趋势git config --global init.defaultBranch main还有一个是设置 pull 的默认行为为 rebase这样拉取远端更新时会尽量用变基而不是产生多余的合并提交历史记录更线性。这项不是必须的但对你养成清晰提交历史的习惯帮助很大git config --global pull.rebase true3. 核心概念与初始化理解仓库是怎么转起来的3.1 工作区、暂存区、版本库的关系Git 最大的门槛不是命令多而是三个概念没理解清楚工作区Working Directory、暂存区Staging Area/Index、版本库Repository/Commit History。打个比方工作区就是你电脑上真实的文件夹你能看到的所有文件都在这里。暂存区像是一个“候机厅”你文件改了之后需要先git add把文件送进候机厅最后用git commit把这些文件打包成一个不可变的版本永久记录在版本库里。很多人卡在git add和git commit为什么要分两步直接用一条命令不行吗其实分两步的好处是让你可以对每一次提交做精细控制。比如你改了 5 个文件但其中 3 个是功能 A2 个是功能 B完全可以用两次git add 两次git commit生成两条干净的提交记录而不是混在一起一大坨。命令上很简单# 添加所有改动到暂存区 git add . # 提交到版本库 git commit -m 提交说明如果你想跳过 add直接提交所有已跟踪文件的改动可以用git commit -am 说明但注意这个命令会把已跟踪文件的改动全部提交不会包含新创建的文件所以新文件还是得先 add。3.2 初始化仓库与 .gitignore新项目想用 Git 管理执行git init就会生成一个隐藏的.git目录这个目录里存放着这个仓库的所有历史信息、分支信息、配置信息。之后的所有版本记录都记录在这个.git里千万不能随便删除。初始化完成后下一步是写.gitignore文件。这个文件用来声明哪些文件或目录不应该被 Git 跟踪。常见的需要忽略的内容包括依赖文件夹node_modules/、vendor/这类的文件量巨大提交进去毫无意义编译产物dist/、build/、*.class、*.o环境配置文件.env、config.local.js里面往往有密钥和数据库地址IDE 和系统文件.idea/、.vscode/、.DS_Store、*.swp我见过最夸张的一个案例同事把node_modules提交到仓库里整个仓库瞬间多了十几万个小文件clone 一次要好几分钟而且每次 pull 都可能产生巨量冲突。这种事经历一次就终身难忘.gitignore的重要性了。3.3 Git 目录泄露一个常见的项目安全隐患热词里出现了“git目录泄露如何下载”这其实是一个安全相关的问题。所谓 Git 目录泄露指的是网站部署时把.git目录一并上传到了服务器导致任何人可以通过访问网站地址/.git/直接下载到整个项目的源码与历史版本。从防御角度说部署前一定要保证.git目录不在 Web 访问目录内或者用服务器配置禁止访问/.git开头的请求。这个信息虽然不属于日常操作但值得在团队里强调因为它往往是安全扫描中最常见的高危项之一。4. 日常高频操作每天都要打交道的 git 命令4.1 查看状态与提交历史我从实际使用的角度来说在 Git 的命令集里最高频的三个命令应该是git status、git log、git diff。git status用来查看当前工作区的状态哪些文件被修改了、哪些文件在暂存区、哪些文件没被跟踪一目了然。这个命令没有副作用随便敲、随便看养成先看状态再操作的肌肉记忆能避开大量低级错误。git log用来查看提交历史。默认输出会有点长用git log --oneline --graph --decorate --all可以输出一个简洁版的带分支关系的图表我几乎每次都这么敲。git diff用来查看工作区和暂存区之间的具体差异。如果想看某个具体文件的变化直接加上文件路径git diff 文件名这三个命令搭配使用能让你随时掌握自己的仓库处于什么状态尤其在冲突、合并、回滚等复杂操作之前先看一眼状态总没错。4.2 拉取远程代码到本地热词里有“git拉取远程代码到本地”这个场景太常用了。两种方式要分清第一次拿到一个项目的地址时用 clone 一次性把整个仓库拉下来git clone https://github.com/user/repo.git git clone gitgithub.com:user/repo.git第二种是仓库已经 clone 过了别人往远端推了新的提交你要把这些更新拉下来git pull这里提醒一点git pull实际上是git fetchgit merge的组合。如果你只执行git fetch远端更新只会下载到本地仓库的“远端跟踪分支”里你看不到代码变化但也不会影响当前工作内容。当你确认当前改动不会和远端的更新冲突时再执行git merge或git rebase。如果拉取时报local changes would be overwritten by merge说明你本地有未提交的修改且修改的文件和远端更新的文件重叠了。解决方式一般是# 临时保存本地改动 git stash # 拉取更新 git pull # 恢复本地改动 git stash pop4.3 提交信息规范与 amend 用法提交信息是项目的重要沟通渠道。我见过不少团队的提交信息全是“update”“fix”“改了点东西”时间一长根本不知道这个提交干了什么。推荐使用简单约定feat: 新增了某个功能fix: 修复了某个 bugdocs: 更新了文档refactor: 重构了代码不改变功能chore: 维护性工作依赖升级等热词里专门提到了git commit --amend这个命令的作用是修改上一次提交的信息或者把新的改动合并进上一次提交里。场景是这样的你刚提交了代码结果发现漏了一个文件没加或者提交信息里有个错别字不需要新建一个提交去“擦屁股”直接git add 漏掉的文件 git commit --amend执行后 Git 会打开编辑器让你修改提交说明。最方便的是直接用-m一次性搞定git commit --amend -m 修正后的提交信息这里有个大坑amend会改变提交的哈希值所以只适合修改“还没有推送到远端的提交”。如果已经 push 过了再 amend 会导致本地历史和远端不一致强行推送会被人骂轻则冲突重则重写共享历史非常不建议。4.4 撤销与回滚后悔药的选择题Git 之所以让人放心就是因为大多数操作都能“反悔”但反悔方式有好几种不少新手容易混。改乱了工作区的文件想恢复到上一次提交的状态git restore 文件名旧版本命令是git checkout -- 文件名。这个操作会丢弃当前工作区未暂存的修改不可逆。已经 add 到暂存区了想撤销暂存git restore --staged 文件名。这个操作不动工作区文件只是把文件移出暂存区。提交了但想撤销这个提交同时保留改动git reset --soft HEAD~1。相当于退回提交前改动还在暂存区。提交了且想把改动也丢了git reset --hard HEAD~1。这个非常危险会彻底删除提交和对应改动。想撤销一个已经 push 的提交更推荐用git revert HEAD。revert 会生成一个新的提交反向应用之前的改动不会破坏历史适合协作分支。用我的话总结一下reset是“回到过去”适合自己没推走的提交revert是“打补丁抵消”适合公共分支。这两个区别一定要记牢很多人就是在 push 后乱用 reset 导致同事拉下来的代码莫名其妙消失。5. 分支管理多线协作的核心5.1 创建分支与切换分支分支是 Git 最强大的设计之一。它允许你在同一份代码库上并行开发不同的功能互相之间不受干扰。想象一下你正在开发 A 功能突然线上有个 bug 马上要修复你只需要切换到master/main分支开一个hotfix分支去修 bug修完合并回主分支再切回 A 功能分支继续干活。这一切只需要几条命令# 创建并切换到新分支 git checkout -b feature/login # 或者使用新版命令 git switch -c feature/login # 列出所有分支 git branch -a # 切换分支 git checkout main日常开发中我不太建议直接在main分支上随便提交代码最好每次都基于main拉一个功能分支开发完合并回去再删除分支。这样 main 分支永远是干净、可发布的这个习惯在团队协作里可以有效减少冲突。5.2 合并分支与冲突处理合并不复杂复杂的是冲突。执行git merge 功能分支名如果两个分支改了同一个文件的同一行Git 没办法替你决定就会在文件里插入冲突标记 HEAD 当前分支的内容 被合并分支的内容 feature/login处理方式很简单手动编辑这个文件把冲突标记和多余的内容删掉留下你想要的结果然后git addgit commit完成合并。冲突并不可怕它反而是好事说明 Git 检测到了会导致逻辑不一致的修改。真正重要的是处理冲突后一定要仔细测试别因为表面上一行代码的取舍导致功能出问题。5.3 git worktree一个被低估的坑热词里出现了git worktree。这个命令是 Git 2.15 引入的功能允许你在同一份仓库下创建多个工作目录每个目录可以检出一个不同的分支。为什么需要它想象一个场景你在 feature 分支上开发到一半突然需要临时跳到另一个分支去修 bug但本地有未提交的修改又不想 stash。你可以git worktree add ../project-hotfix hotfix-branch这样会在上级目录开一个project-hotfix文件夹里面检出的是hotfix-branch可以完全并行操作。我之前在维护多个版本的场景下用 worktree 同时开 main、dev、release 三个目录切换起来极其流畅。用完后记得清理git worktree remove 目录路径 git worktree prune这个功能我在团队里推荐过第一批用的人不怎么多但上手后基本都回不去了。尤其是需要快速验证不同分支兼容性的时候比反复切换分支、腾挪工作区要高效太多。5.4 stash临时保存半成品git stash用来把当前工作区的未提交修改暂时保存起来使得工作区回到干净状态。等忙完别的事情再恢复。常用操作# 保存 git stash # 恢复最近一次 stash git stash pop # 查看 stash 列表 git stash list # 恢复指定 stash git stash apply stash{1}pop和apply的区别在于pop会恢复并删除这个 stash 记录apply只恢复不删除。我通常用pop除非同一个 stash 要在多个分支复用。有一个易错点如果你 stash 的修改涉及的文件和当前分支中的版本差异很大恢复时也可能冲突但概率不大处理好即可。6. 远程仓库与 SSH 密钥从本机到服务器的最后一公里6.1 clone、push、remote 的完整流程本地仓库和远程仓库的关联是通过 remote 配置实现的。clone 项目时远程仓库地址会被自动设置为origin这也是为什么你总能看到git push origin main这种写法。日常推送流程# 查看远程信息 git remote -v # 添加远程仓库 git remote add origin https://github.com/user/repo.git # 推送本地分支到远程 git push -u origin main-u参数的作用是建立本地分支和远程分支的关联第一次推送后后续直接git push即可不用每次写远程和分支名。推送时如果远端比本地领先Git 会拒绝推送提示git pull一下再推这是保护机制防止你覆盖别人提交的内容。遇到这种情况就老老实实 pull 再处理冲突不要加--force强推。强推真的会毁灭历史尤其多人协作时会导致别人的提交凭空消失。6.2 Gitee 与 GitHub 的 SSH 密钥配置SSH 密钥的作用是让你在推送代码时免去反复输用户名密码。从 Git 官网下载安装时一般会自带 OpenSSH所以 Windows 下配置 SSH 也很方便。先检查本机是否已有密钥ls ~/.ssh如果不存在id_rsa和id_rsa.pub文件就生成一个新的ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车即可也可以设置密码短语passphrase不过日常用建议留空省得每次操作都要输密码。生成后打开公钥文件cat ~/.ssh/id_rsa.pub把输出的内容复制然后登录 Gitee 或 GitHub在“设置 - SSH 公钥”里粘贴保存。之后测试连接# GitHub ssh -T gitgithub.com # Gitee ssh -T gitgitee.com如果看到Hi xxx! Youve successfully authenticated说明配置成功。此时 clone 远程仓库时记得用 SSH 格式的地址gitgithub.com:user/repo.git而不是 HTTPS 地址才能免密推送。6.3 配置 Gitee 密钥时遇到的经典报错我在配置 Gitee 密钥时最常见的一个报错是ssh: connect to host gitee.com port 22: Connection timed out。这种情况在国内网络环境里时有发生很多文章会建议换 443 端口来规避。修改方式是在~/.ssh/下新建或编辑config文件Host gitee.com HostName gitee.com Port 443 User git保存后再次执行ssh -T gitgitee.com。这个方案在多个云代码平台都适用本质上是利用 SSH over HTTPS 的方式绕过 22 端口的限制。我当年就靠这个解决了公司内网环境下的推送问题。6.4 Git 免密配置与账号密码保存如果你用的是 HTTPS 方式 clone 的仓库推送时会要求输入账号密码。Windows 下生成一次凭据后Git 一般会记住。但某些环境下没有启用凭据管理器每次都提示输密码很烦。可以执行git config --global credential.helper store这个方式会把凭据明文存储在用户目录的.git-credentials文件里。在自己的个人电脑上问题不大但在公用机器上不太安全建议用 Windows 自带的凭证管理器git config --global credential.helper manager另外还有一个技巧是在远程地址里直接内嵌账号信息比如git remote set-url origin https://用户名:密码github.com/user/repo.git这个方式我不推荐在真实项目中使用因为密码暴露在 bash 历史里一旦历史被翻出来就凉了。稳妥的做法还是用 SSH 密钥。7. 可视化与编辑器集成IDEA、VS Code 里的 Git 玩法7.1 IDEA 里的 Git 提交与推送热词里有“idea怎么用git提交代码”JetBrains 系 IDEIDEA、PyCharm、GoLand的 Git 集成做得很成熟。操作上改完代码后左侧的文件会变色蓝色表示修改绿色表示新增在项目根目录或文件上右键选Git - Commit Directory...左侧会列出所有改动文件勾选要提交的填写 Commit Message点 Commit 或 Commit and Push。比较顺手的功能是在提交面板里可以直接显示 diff点击文件即可查看改动详情。使用Ctrl K打开提交窗口Ctrl Shift K推送。底部工具栏的 “Log” 标签页可以看到分支图和提交记录非常直观。IDEA 里要设置好 Git 路径Settings - Version Control - Git。如果提示找不到 Git多半是环境变量没有生效或者你用了便携版 Git。7.2 VS Code 与 Git 插件VS Code 默认自带 Git 支持左侧的“源代码管理”图标可以直接看到改动文件列表。输入提交信息后点对勾图标提交然后点“同步更改”推送。如果想可视化分支和合并推荐安装 GitLens 或 Git Graph 插件。Git Graph 能直接绘制出分支走向图对理解整个仓库的演进历史特别有帮助。GitLens 则能显示每一行代码的最后修改者定位问题责任人的时候非常好用。我日常在写代码时会开着 Git Graph每次提交后看一眼分支图整个项目脉络清清楚楚。可视化工具和命令行并不冲突熟练后可以混用怎么高效怎么来。7.3 网上热传的git -c diff.mnemonicprefixfalse ...是什么热词里有一条很长的命令git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks这其实是某些 GUI 工具比如 SourceTree在底层调用 Git 时的参数配置。-c表示临时指定某个配置项不写入全局配置。core.quotepathfalse表示让 Git 在输出文件路径时不转义非 ASCII 字符解决中文文件名显示为\346\226\207\344\273\266这种乱码的问题。如果你在命令行里看到 Git 输出的中文路径是转义序列可以直接设置git config --global core.quotepath false这个配置对中文用户是刚需。至于diff.mnemonicprefix和--no-optional-locks日常手动操作基本用不到不用理会。8. 常见问题与排查实录8.1 fatal: not a git repository (or any of the parent directories): .git这个报错我之前刚入门时天天遇见。原因是当前目录根本不是 Git 仓库或者你的命令敲错了层级。解决方式执行ls -a看看有没有.git目录。如果没有说明当前文件夹还没初始化执行git init。如果有.git目录但命令仍然报错看看你是不是在.git目录内部执行了git branch之类的命令Git 不允许在这个目录里直接操作。还有一个隐蔽的场景用 Windows 的 CMD 时如果你在某个子目录下克隆了一个项目然后切到父目录执行 git 命令也会报这个错。解决方案就是先cd到对应仓库根目录下再操作。8.2 login failed. check api token or gitlab version这句话不是 Git 本身的报错而是某些 Git 桌面客户端或编辑器插件连接 GitLab 时的认证失败提示。常见原因有GitLab 账号没有正确配置 Access Token 或 API Token。个人访问令牌过期了。GitLab 默认可以为 token 设置过期时间。GitLab 版本过低新版 API 和旧版客户端不兼容。你在公司内网访问代理设置干扰了 API 请求。处理思路是先去 GitLab 个人设置里生成一个新的 token保证权限至少包含read_repository和write_repository。然后在客户端里重新填写。如果依然失败检查是否在 IDE 插件里填错了 GitLab 地址有些环境要用内部域名而不是外网入口。8.3 Git Bash 中文乱码问题Git 在 Windows 下显示中文文件名或提交信息时乱码原因基本都是编码问题。核心思路是让 Git 对所有输入输出都使用 UTF-8。核心配置git config --global core.quotepath false git config --global gui.encoding utf-8 git config --global i18n.commit.encoding utf-8 git config --global i18n.logoutputencoding utf-8如果提交信息在 Git Bash 里显示正常但 IDEA 里乱码那就要去检查 IDEA 的文件编码设置统一改成 UTF-8。8.4 提交错分支把 A 分支的改动提交到 B 分支了这种问题几乎每个人都会遇到。处理方式我记得特别清楚。假设你本想在feature/login开发结果在main分支上改了文件并提交了。要修正的做法是# 回退提交但保留改动 git reset --soft HEAD~1 # 把改动 stash 起来 git stash # 切到正确的分支 git checkout feature/login # 恢复改动 git stash pop # 重新提交 git add . git commit -m feat: 登录功能这个流程的核心是reset --soft加stash整个过程不会丢失任何代码改动。我就是靠这个流程帮团队伙伴抢救过好几个“提交串台”的现场。8.5 误删分支后的恢复分支被误删通常还有救。git branch -D删除分支后分支最后一次提交的哈希仍然存在。如果你还记得大概的提交信息可以用# 查看所有历史提交包括被删分支的 git reflog show --all # 通过提交哈希重新创建分支 git checkout -b 分支名 提交哈希reflog是 Git 的“操作日志”记录了你本机执行过的几乎每一次 HEAD 移动。它不等于提交历史但能帮你找回大量“以为丢了”的分支和提交。我在一次误删分支后就是靠 reflog 找回了一个带大量工作成果的分支从那以后我对 reflog 一直很敬畏。9. 实操心得与个人经验分享按我自己的使用习惯Git 最有价值的地方不是它能记多少版本而是它给了我一种“随便改、不怕乱”的安全感。文件改废了可以回滚分支切错了可以恢复提交写错了可以改造。这种安全感是写代码时极大的心理支撑。不过我也走过弯路。买了课程、背了命令表真正入门其实是从“强制自己把 IDEA 里的操作换成命令行”开始的。用命令行不是装而是逼着自己理解每一步在干什么。等你理解之后再回到 IDEA、VS Code 的图形界面你会发现所有按钮都变得透明了你知道它背后执行的是一条什么命令也知道它操作的是工作区还是暂存区。最后分享一个小技巧如果你刚接手一个项目别急着改代码先用git log --oneline --graph --all看一遍分支结构和提交历史再跑到git reflog里看一眼近期的操作记录基本能猜出团队协作的节奏和习惯。这种“先看历史再动笔”的做事方式平时看起来不起眼关键时刻能帮你避掉大坑。
