做开发这些年几乎每天都要跟 Git 打交道。不管是个人维护开源项目还是团队协作改一个线上服务版本管理都是绕不开的一环。Git 之所以能成为事实标准不在于命令多而在于它的核心工作流足够顺手改代码、提交、分支、合并、推送一套动作下来版本就有了清晰的历史脉络。这篇内容就以 Git 基本工作流为主线把安装配置、日常命令、分支协作、冲突处理和那些让人头疼的疑难杂症都过一遍适合刚把 Git 装好、还没完全上手的同学也适合用了很久但老是靠“背命令”过日子的老兄——看完你会知道每条命令背后到底在做什么。很多人学 Git 卡住不是因为命令难而是因为脑子里没有一张“图”。Git 不像 SVN 那样只有“中心仓库”和“工作副本”两个概念它把人搞晕的恰恰是本地也有完整版本库这件事。所以我不打算上来就扔一张命令清单而是先带你建立工作流的整体认知再一步步拆解每个环节的细节和坑。这样后面无论遇到什么奇怪报错你都能自己定位问题。1. 先把基础打好Git 安装与环境配置1.1 不同系统的安装方式先说装 Git。这一步看着简单但很多人装完发现命令行里敲git没反应或者 IDE 里显示 Git 路径不对全是安装时埋下的雷。Windows 用户最稳妥的方式是去 Git 官网下载安装包。装的时候有几个选项值得注意一是“Adjusting your PATH environment”默认推荐的第二项“Git from the command line and also from 3rd-party software”一定要选这样你在 CMD、PowerShell 和 IDE 里都能直接调用 git二是“Checkout style”里选“Checkout Windows-style, commit Unix-style line endings”这是默认值能避免大部分换行符问题。安装包体积不大装完打开 PowerShell 输入git --version能输出版本号就算成功了。如果提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”多半是 PATH 没生效重开终端或注销一次就行。macOS 上有三条路用 Xcode Command Line Tools、用 Homebrew、用官网 dmg。最省心的是 Homebrew一条brew install git就完事以后升级也方便。Linux 各发行版则用自带包管理器Ubuntu/Debian 是sudo apt install gitCentOS/RHEL 是sudo yum install git。无论是哪种系统装完第一件事永远是git --version确认。还有一个很多人忽略的点如果你用的是 IDEA、VS Code 这类 IDE它们内置的 Git 插件不一定走系统 PATH。遇到“无法找到 Git 可执行文件”的提示去 IDE 的版本控制设置里手动定位git.exe或/usr/bin/git路径就行。macOS 上装了 IDEA 但识别不到 Git常见原因就是没装 Xcode Command Line Tools装完就好了。1.2 装完必做的三件事安装只是开始真正决定你后续体验的是配置。这里说的配置不是那些花里胡哨的别名而是最基本的用户信息、换行符和默认文本编辑器。用户信息是提交记录的“签名”没配的话每次 commit 都会报错。打开终端执行git config --global user.name 你的名字 git config --global user.email 你的邮箱注意这里的邮箱最好和你的代码托管平台Gitee、GitHub、GitLab绑定邮箱一致这样提交记录能正确关联到你的账号。--global表示对当前用户全局生效如果某个特定仓库想用不同的身份可以在那个仓库目录下去掉--global再设置一次。换行符问题我多说两句。Windows 默认换行符是 CRLFLinux/macOS 是 LF。如果不处理同一个文件在 Windows 和 Linux 之间来回 checkout 时Git 会认为整个文件都改了diff 直接爆炸。我在前面提到的安装默认选项就能解决大部分问题。如果你已经装完了也没关系手动设置一下git config --global core.autocrlf true # Windows 用户 git config --global core.autocrlf input # Linux/macOS 用户这样一来Git 在 Windows 上 checkout 时会把 LF 转成 CRLF提交时再转回 LF仓库里永远存的是 LF跨平台协作就不会互相伤害了。1.3 账号凭据与免密配置配置好身份后下一步是让 Git 记住你的账号不然每次 push/pull 都输密码用不了几次就烦了。先说 HTTPS 方式。Windows 上装 Git 时会默认启用“Git Credential Manager”第一次输入账号密码后会被安全存在 Windows 凭据管理器里之后自动免密。如果发现没生效可以手动开启git config --global credential.helper managermacOS 则用osxkeychaingit config --global credential.helper osxkeychainLinux 可以选择store纯文本存用户目录不推荐在共享机器上用或者cache只缓存内存一段时间。我个人在 Linux 服务器上更习惯用 SSH 方式后面一节细说。要清除已经保存的账号密码Windows 可以去“控制面板-凭据管理器”里删除对应的 git 凭据或者用命令git credential-manager github logout git credential-manager eraseVS Code 里如果你发现总是弹出登录框、反复让你输密码多半是凭据管理器没配好。先把git config --global --list拿出来看一眼确认 credential.helper 有值再测试一次 push 让它记住就好。1.4 SSH 密钥配置与认证失败排查SSH 的好处是一旦配好密钥所有 Git 操作都免密而且更安全。生成密钥很简单ssh-keygen -t ed25519 -C 你的邮箱一路回车会在~/.ssh/id_ed25519.pub生成公钥。然后把公钥内容添加到 Gitee 或 GitHub 的“SSH 公钥”设置里。添加完成后测试ssh -T gitgitee.com如果看到欢迎信息说明密钥没问题。这里有个常见的坑克隆仓库时用了 HTTPS 地址但你把密钥配到了 SSH 上那自然还得输密码。另外在 Gitee 上正确的主机名是gitee.com端口默认 22 不通的时候可以试 443 端口ssh -T -p 443 gitssh.gitee.com“ssh认证失败”这类问题我排过很多次80% 是三种原因公钥没加到平台、克隆地址用错HTTPS/SSH搞混、本地有多个密钥导致 Git 用了错误的私钥。第三种可以用~/.ssh/config指定某个 host 使用哪个密钥文件Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519写完这个配置记得chmod 600一下私钥文件不然权限太开放SSH 会拒绝使用。2. 基本工作流核心工作区、暂存区与提交2.1 先理解三个区域和文件状态我一直觉得Git 的命令记不住本质上是因为不理解它把文件拆成了三个区域工作区Working Directory、暂存区Index/Staging Area和本地仓库Repository。工作区是你编辑器里看到的文件暂存区是一个临时存放“准备提交的改动”的地方本地仓库才是真正记录历史的地方。这套设计和 SVN 最大的区别在于SVN 只有“提交”一步而 Git 把“准备提交”和“真正提交”分开了。这个设计的好处是你可以只提交一部分改动、把另一部分继续留在工作区方便按逻辑拆分成多个 commit。坏处是新手上手时容易懵为什么git status里文件有的是红色、有的是绿色红的代表有改动但还没暂存绿的表示已经加入到暂存区、等待提交。理解了这个再看git status就很简单了。那些“Changes not staged for commit”就是工作区的改动“Changes to be committed”就是暂存区的改动。日常操作过程中我会习惯每隔几分钟就跑一次git status它会把当前仓库状态、当前分支、有哪些修改全部告诉你是排查问题的最好入口。2.2 日常提交循环add、commit、status、log一次完整的本地提交流程是这样git status # 查看状态 git diff # 查看具体改动内容 git add file # 把文件加入暂存区 git commit -m 提交说明 # 提交到本地仓库git add的粒度可以很灵活。你可以git add .把所有改动加进去也可以只git add src/xxx.js只提交某个文件还可以用git add -p交互式地把一个文件里的不同代码块拆开提交。最后这个技能非常实用因为“一个 commit 只做一件事”是好习惯但实际开发时经常会一个文件里改了多处不同逻辑用-p就能手动分割。commit 信息的写法也有讲究。我见过最头疼的提交信息是“fix bug”或“修改”等过三个月回看历史完全不知道当时改了什么。我个人的习惯是第一行用一句祈使句概括动作比如“修复订单金额计算精度问题”如果改动较大就空一行再写一段详细说明说明里交代“为什么这么改”而不是复述代码改了什么。这种写法在git log --oneline里看得特别清楚。git log还有几个好用的参数git log --oneline -5看最近五次简明记录git log --stat看每次提交改了哪些文件git log -p直接看 diff。我排查问题时最常用的是git log -S某个关键词它能找出“哪个 commit 新增或删除了包含某个关键词的行”这在定位历史 bug 时简直救命。2.3 从远程拉取项目clone 与 IDE 集成进入团队协作的第一步通常是拉取远程仓库对应命令是git clone 仓库地址 [目录名]这里的地址可以是 HTTP 也可以是 SSH。我在前面强调过如果已经配好了 SSH 密钥就用 SSH 地址一劳永逸。clone 完成后Git 会把远程仓库完整下载下来并自动建立名为origin的远程别名和本地的主分支同时切换到本地分支上。IDE 集成方面IDEA 里新建项目从 Git 拉取很简单File → New → Project from Version Control粘贴仓库地址一路下一步。VS Code 则是在源代码管理面板里选“克隆仓库”。我自己的经验是不要在 IDE 里用不熟悉的图形化按钮操作分支合并等命令用熟了再回去用图形界面心里会踏实很多。IDE 的 Git 面板适合看状态、看 diff、做 commit但分支操作和冲突解决命令行反而更清晰。一个经常踩的坑是克隆时如果仓库里有 Git LFS 大文件而本地没装 LFS文件会被拉成一个几 KB 的文本指针真正的文件内容不会下载。遇到这种情况先安装 Git LFS再执行git lfs pull手动拉取。后面我会专门讲 LFS。2.4 本地项目接入远程仓库的流程不是所有情况都需要 clone。很多时候是你先在本地写了一堆代码还没建远程仓库现在要把整个项目推上去。流程其实很固定。以 Gitee 为例先在网页端创建一个空仓库不要勾选“初始化仓库”选项然后回到本地项目目录git init # 把当前目录变成 Git 仓库 git add . git commit -m 初始提交 git branch -M main # 把当前分支改名为 main git remote add origin 仓库地址 git push -u origin main # 推送到远程并设置上游关联如果远程仓库在网页端已经初始化过生成了 README、.gitignore 等本地直接git push会报错“refusing to merge unrelated histories”。这时候有两个选择一是接受远程已有的初始化内容先把远程内容拉下来再合并二是你确认远程是空仓库强制推上去git pull origin main --allow-unrelated-histories # 或者你觉得远程那个初始提交没意义反过来覆盖它 git push -u origin main --force--force是危险操作会覆盖远端历史团队协作时慎用如果是自己一个人用刚建的空仓库就没那么敏感。但我建议就算是一个人也要先想清楚再 force形成习惯后将来就不至于在别人没注意的时候把同事的提交冲掉。3. 分支合并是协作的命脉3.1 分支的创建、切换与合并分支是 Git 最值得炫耀的功能。它本质上只是一个指向某次提交的指针所以创建分支的成本几乎为零这也是 Git 和 SVN 在协作模型上最大的差异SVN 的分支是目录拷贝又慢又占空间Git 的分支就是一张便利贴随时贴随时撕。基础操作就三个git branch feature/login # 创建分支 git checkout feature/login # 切换分支 git switch feature/login # 切换分支新版推荐git switch是 Git 2.23 之后推荐使用的命令语义上比checkout清晰。但服务器和老教程里常见checkout所以两种都要认得。创建并切换一步到位用git switch -c feature/login或git checkout -b feature/login。合并分支时推荐一个我用了很久的保守策略先把主分支更新到最新再切回功能分支把主分支合并进来或者用 rebase后面说解决掉所有冲突最后再切回主分支做合并。这样能让主分支始终保持干净的历史冲突也更容易定位。git checkout main git pull origin main # 确保主分支是最新 git checkout feature/login git merge main # 把主分支的新内容并入功能分支 git checkout main git merge feature/login # 功能开发完合并回主分支 git push origin main这里要提醒一个新手常见的操作失误在主分支上直接改代码忘记先开功能分支。等你 push 的时候才发现和别人的改动全搅在一起。每次开始新功能前先问自己一句“我现在在哪个分支”这是一个值得养成肌肉记忆的操作习惯。3.2 merge 与 rebase 的选择合并分支有两条路merge和rebase。这俩经常争得不可开交我讲清楚区别你自己选。merge会生成一个额外的“合并提交”保留了两个分支真实的汇合点历史是网状的能看出来“这里并进来过一件事”。优点是不改动已有提交安全缺点是历史图不太直时间长了会乱。rebase会把当前分支的提交“拆下来”一个一个重新打到目标分支的顶端上历史变成一条直线。优点是干净整洁缺点是它会改写提交的哈希和时间属于“改写历史”的操作千万不要在已经推送出去、别人也在用的分支上随便 rebase。我个人的习惯是还没有推送到远程的本地功能分支用 rebase 把主分支的新更新整合进来已经推送到远程、并且涉及多人协作的分支老老实实用 merge 或创建新的合并请求。一句话公共分支上别 rebase私有分支上随便玩。3.3 冲突的产生和解决流程冲突是 Git 协作里绕不过去的坎也是很多人最怕的东西。其实冲突的本质就是 Git 无法自动决定到底听谁的需要人来判断。最典型的场景是 A、B 两个人同时改了同一个文件的同一行。B 在 merge 时会看到这样的标记 HEAD 当前分支的内容 被合并分支的内容 feature/login这个标记把冲突区域圈出来了到是当前分支的版本到是外来分支的版本。你在编辑器里把它改成最终想要的样子删掉那三行标记保存文件然后git add 解决完的文件 git commit冲突解决完成。整个过程 Git 不会替你决定“保留谁”只会把选择权交给你。我见过很多新手在冲突时慌不择路乱删标记导致文件语法错误。建议记住一个原则先读代码理解两边各自的意图而不是“谁的代码留下来”。如果两个人改的是同一个逻辑更稳妥的方式是把两边的人叫到一起确认最终的实现再合并。冲突本身也不是坏事它说明团队确实在同一块业务上投入了两股不同的力只是需要一个明确的主导者。另一个减少冲突频率的操作是功能分支存活时间不要太长。一个分支拖了三周主分支早就翻天覆地合并回来时的冲突规模肯定让人崩溃。小而短的分支是 Git 协作最健康的节奏。3.4 修改历史amend 与交互式 rebasegit commit --amend是我平时用得挺多的一个命令。它的作用是修改“最近一次提交”可以改提交信息也可以把当前暂存区的改动偷偷塞进上一次提交里。比如我写完一个 commit 后发现少了个文件或者提交信息写错了字git add 遗漏的文件 git commit --amend执行完会打开编辑器让你改提交信息如果只是想保留原有信息、只补充文件可以用git commit --amend --no-edit。但注意amend同样会改写提交哈希。如果这个 commit 已经 push 到远程了而且有别人拉下来过就不要 amend 了不然下次 push 会被拒绝你不得不再走一次 force push很可能扰乱别人的仓库。想改更早的历史用交互式 rebasegit rebase -i HEAD~3界面会列出最近三个提交你可以在每个提交前改成pick、squash合并到前一个、edit停下来修改、reword改信息等操作。这个功能很强大但建议只在本地分支上用。我自己的用法是在把功能分支推到远程前用交互式 rebase 把一堆零散的“wip”“fix typo”压缩成一个干净完整的提交这样合并请求里看到的历史就很清晰。4. 大文件、效率工具与仓库维护4.1 Git LFS大文件管理的正确姿势普通 Git 仓库是为文本设计的把所有文件的历史都存在.git目录里。如果仓库里混入了大文件比如设计稿、模型、数据集每次修改都会让仓库体积疯狂变大clone 一次慢到怀疑人生。Git LFSLarge File Storage就是解决这个问题的它把大文件的实际内容移到远程服务端仓库里只保留一个几十字节的指针文件需要真实内容时再按需下载。安装和使用都很简单git lfs install git lfs track *.psd git lfs track *.zip git add .gitattributes之后这些类型的大文件提交、推送、拉取都由 LFS 接管。克隆一个带 LFS 的仓库前确保本地已经安装了相同版本的 Git LFS如果 clone 到一半卡住很可能是某个大文件特别大Git 正在后台下载别急着 CtrlC先看输出信息。也可以用git lfs clone和git lfs pull来分别处理不过新版 Git 已经把 LFS 集成得比较好了。LFS 的坑在于它的数据也是有限额的Gitee 免费用户有固定容量和流量限制用超了就拉不动。我的建议是能用压缩包或 CDN 管理的大文件别放进 Git 仓库真正需要随代码版本走的大文件才进 LFS。4.2 worktree一个目录并行管理多个分支有时候你需要同时开好几个分支干活。比如当前工作区正改着某功能临时被叫去修复一个线上 bug但手头改动还没提交git switch会直接阻止你切过去。常规做法是 stash 暂存当前改动另一种更清爽的办法是git worktreegit worktree add ../hotfix bugfix/urgent-fix这条命令会在../hotfix目录下新建一个工作区专门服务于bugfix/urgent-fix分支。你可以在这个新目录里做紧急修复、提交、推送完全不影响原目录里没提交的改动。修完再看git worktree list git worktree remove ../hotfix这个功能特别适合需要在多个分支并行发版、或者经常跨分支比对着改代码的场景。我用了之后基本摆脱了“切分支前先 stash”的繁琐流程。4.3 清理、还原与撤销操作指南Git 操作里撤销永远比提交复杂。我整理一下不同场景的处理方式如果改了文件但还没git add想放弃所有改动用git checkout -- file # 或者新版写法 git restore file如果已经git add了但还没 commit想取消暂存文件内容保留git reset HEAD file git restore --staged file如果已经 commit 了想撤掉这次提交但保留改动内容git reset --soft HEAD~1如果想连改动一起丢弃就用git reset --hard HEAD~1这个操作很危险改动直接没了。我的建议是执行--hard前先把当前状态存个备份分支或者git stash兜底哪怕操作失误也能找回。还有一个高频场景是.gitignore没配好把不该提交的目录比如 node_modules、target、.env提交上去了。解决办法是先写对 .gitignore然后git rm -r --cached node_modules git commit -m 移除误提交的目录--cached表示只从 Git 索引中移除不动本地文件这样既清理了仓库又不影响你本地继续使用这些目录。这套操作我在接手老项目时经常用一遍就能把仓库体积瘦下来。5. 常见报错与实战排坑速查5.1 高频报错对照表做 Git 培训这几年我把团队成员问得最多的问题整理成了一张速查表基本能覆盖 90% 的日常故障。报错信息 / 现象含义解决方式fatal: not a git repository (or any of the parent directories): .git当前目录及上级目录都不是 Git 仓库git init初始化或者确认你是否 cd 错了目录unable to access ... OpenSSL SSL_read: Connection was resetHTTPS 访问远程仓库失败检查网络确认远程仓库地址是否可达fatal: refusing to merge unrelated histories两边仓库历史没有共同祖先刚建新仓库时用--allow-unrelated-histories合并ssh: connect to host ... port 22: Connection refusedSSH 端口不通改用 HTTPS 地址或改用 SSH 的 443 端口配置error: Your local changes would be overwritten by checkout/merge本地有未提交改动切分支会覆盖先 commit、stash 或记录备份再切换fatal: Authentication failed for ...认证失败检查账号密码是否输对、凭据管理器是否配置、SSH 密钥是否公钥The following untracked working tree files would be overwritten by merge合并时被未跟踪文件挡住把文件移走或删除后重新合并查明是否被 .gitignore 忽略git lfs clone 卡住LFS 大文件下载慢或卡住检查 LFS 是否安装确认是否有超出限额的大文件适当等待或分批拉取这张表里的第二条值得多说一段。如果你在 clone 或 push 一个很大的仓库时反复断线一种有效方式是改用 SSH 协议。如果 SSH 也不稳定还可以考虑用代理或 CDN 等方式拉取镜像。但无论如何先确认自己本地依赖是不是太久没更新旧版 Git 对部分新协议支持不好也会造成莫名的连接问题。先把 Git 升级到最新稳定版能少踩不少坑。“无法将‘git’项识别为 cmdlet”这个报错出现的原因和解决方案我在第一节讲过。这里补充一个运维小技巧Windows 用户在 PATH 配置完成后可以在 CMD 里执行where gitLinux/macOS 执行which git如果找得到路径说明环境没问题IDE 找不到就是 IDE 自己的设置问题。5.2 Git 目录安全与误提交排查网络上有一些关于“.git 目录泄露”的讨论说的是扫描网站文件时发现.git目录被公开访问导致源码历史被扒走。这个问题的本质是部署或发布项目时误把项目根目录下的.git目录也当作静态文件一起暴露到了线上。作为开发者反过来要检查的其实是自己有没有做过“把仓库整个传给不该传的人”或者“把不该提交的秘密文件传到了远端”。正确的防御动作有两个。第一.gitignore一定要第一时间写好把.env、配置密钥、本地构建目录全部排除。第二提交前养成git status看一眼的习惯别git add .无脑全收。我见过有人把包含数据库密码的配置文件推到了 Gitee 上然后被爬虫扫走这属于安全问题属于事故级别。处理方式是立刻改密码而不是只删文件因为历史记录里还留着。另外还有个小技巧找历史里的敏感信息可以用git log -p配合同步检索工具扫描整个历史确认有没有泄漏后再决定是否需要清理历史。销毁历史是件麻烦事涉及 rewrite所以我更推荐把精力花在“别让敏感信息进历史”这个环节上。5.3 我的排查思路与小技巧排查 Git 问题我有一套自己的固定流程。第一步永远是git status把当前状态看清楚第二步是git config --list确认全局和本地的配置有没有被覆盖第三步是看本地和远程的关系用git remote -v检查地址用git branch -vv看分支跟踪关系第四步才是动手操作。顺手分享几个提高效率的小配置。给常用命令配置别名会让日常操作舒服很多git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg log --oneline --decorate --graph --all配置完后git lg看出的历史图一目了然色彩和结构都很清楚了。还有一个我特别推荐的技巧每个仓库提交前跑一遍git diff --check它会检查有没有尾随空格、空行错误这些格式问题避免无意义的 diff 噪音。团队协作里这种细节反而最能体现提交质量。6. 写在最后的一点个人经验如果需要给 Git 总结一句使用心得我的个人体会是别把它当网盘用。Git 的价值在于它是“有时间线的版本管理工具”核心是提交历史干净、可回溯、可协作。很多你遇到的问题冲突、误提交、大文件爆炸本质上都是没有遵守“小而短的分支、清晰的提交信息、及时的同步”这些习惯引起的。命令本身只有那么几个难得是把工作流养成肌肉记忆。最后再分享一个小技巧如果你不确定某条命令会产生什么后果就去一个临时目录里建一个空仓库随便创建几个文件把命令在上面试一遍。这个成本几乎为零但能让你放心很多。Git 的容错率其实比想象中高只要不频繁 force push、不随意 reset --hard大部分错误都可以用 reflog 找回来。把这些基本工作流练熟了无论是个人项目还是团队协作你都会轻松不少。