1. 从零搭建Git工作环境安装与全局配置Git这个工具只要写过代码、做过文档版本管理应该都接触过。但我发现很多人在“会用”和“用得顺”之间隔着一道坎——不是不懂命令而是环境没配好导致后面每一步都磕磕绊绊。今天这篇就从Git安装、配置一直聊到分支合并、SSH认证这些高频实操把我这些年踩过的坑和筛出来的最佳实践一次说清楚。1.1 Windows下Git安装实操我估计大半读者主力系统是Windows所以安装这块以Windows为例。Git官方提供Windows安装包直接去git-scm.com下载就行。但这个安装过程有几个选项值得注意选择安装路径时建议不要用带空格的目录比如C:\Git或D:\Git这样的纯路径。虽然带空格也能用但后续配合脚本、批处理文件时容易出幺蛾子。到了“Select Components”这步默认勾选“Git Bash Here”和“Git GUI Here”建议保留。Git Bash在Windows下模拟Linux终端环境后面执行SSH命令、写shell脚本都靠它。“Default editor”建议选“Visual Studio Code”或“Nano”。如果你选了Vim每次commit时不小心进入vim界面几十秒出不来是常事新手体验极差。当然老手用vim是信仰问题此处不争论。“Adjusting your PATH environment”这步选择“Git from the command line and also from 3rd-party software”。这样能让Git命令在CMD、PowerShell和Git Bash里都能直接调用省心。换行符处理Checkout Windows-stylecommit Unix-style line endings这步默认选项就行即自动转换CRLF。直接原因后面讲。安装完成后打开Git Bash先验证一下版本git --version能输出git version 2.x.x就说明装好了。很多刚接触Git的朋友在老教程里看到git version 2.30.0之类就会怀疑自己装错其实没有新版本都是这个格式。如果你在Linux或macOS上直接apt install git或brew install git就好装的过程比Windows简单得多。1.2 几个必须改掉的默认配置装好只是开始真正决定使用体验的是全局配置。Git安装后默认没有任何用户信息第一次提交会报错——“Please tell me who you are”。这是好事逼你先把身份设置好git config --global user.name 你的名字 git config --global user.email 你的邮箱注意这里填的名字和邮箱会记录进每次提交的作者信息里。提交到GitHub/GitLab等平台时平台会通过邮箱关联账号。如果你不想让真实邮箱暴露GitHub提供了用户名users.noreply.github.com这种隐私邮箱可以在GitHub设置里生成然后填这个。我建议你顺手做三件配置设置默认分支名为maingit config --global init.defaultBranch mainGit老版本默认分支名是master新版本已经在改。提前统一成main能避免后续无谓的纠结。配置默认推送拉取行为git config --global pull.rebase false这个配置跟工作流习惯有关后面讲分支合并时会详细解释为什么。开启彩色输出git config --global color.ui true改完之后git log、git status的输出会带颜色区分度立刻不一样对判断文件状态非常有帮助。还有一个容易被忽略的细节——换行符。Windows用CRLF回车换行Linux/macOS用LF换行。如果团队里有人用Windows、有人用Linux混着提交会看到整个世界都变成了“modified”的红点。Git的默认方案是检出时转成CRLF提交时转成LF。这套自动转换机制就是刚才安装选项里说的那个默认值一般建议保持默认。但如果你参与的是一个纯Linux服务器部署的开源项目团队约定统一LF那就在项目根目录放一个.gitattributes文件强制规范* textauto *.sh text eollf这样对仓库内所有文本文件统一处理避免个人全局配置影响到别人的环境。2. 高频命令的取舍与调用逻辑配置做完进入正题。市面上讲Git命令的清单一大把但真正干活时常用的其实就十几条。我先讲一下Git底层的数据流再逐条把命令和场景对上。2.1 文件状态流转的底层逻辑Git把文件状态分成四块工作区working directory、暂存区staging area、本地仓库local repository、远程仓库remote repository。平时我们修改文件只是动了工作区。要让修改真正进入版本记录需要走一遍git add filename # 工作区 - 暂存区 git commit -m 说明 # 暂存区 - 本地仓库 git push # 本地仓库 - 远程仓库这套流程的好处是每次提交前你可以有意识地选择“这次提交包含哪些文件”而不是一股脑把工作区所有改动打包。比如你同时改了一个bug和一个新功能完全可以分两次commit每次只add对应文件。这为后续的代码回溯、问题定位提供了清晰的粒度。理解了这个流转很多命令就通了。比如git status看到的Changes not staged for commit表示工作区有改动但还没addChanges to be committed表示已暂存接下来会被commit。我见过太多人上来就git add . git commit遇到多任务并行时整个历史一团乱麻。除非是个人临时项目否则强烈建议“按需add 分次commit”。2.2 提交、回滚与撤销一套组合拳提交本身不复杂真正让人头大的是“改错了想撤销”。Git的回滚体系让人又爱又恨关键在于分清场景场景一改乱了文件想回到某一时刻的干净状态git restore filename这个命令把工作区文件恢复到最近一次commit的状态。注意它只影响工作区暂存区不受影响。这是一个相对“安全”的恢复操作因为丢失的只是你未提交的修改。如果你已经git add了想连同暂存区一起撤销用git restore --staged filename这会把文件从暂存区撤回到工作区但文件内容不会丢失。场景二提交完了发现commit信息写错了git commit --amend打开编辑器修改最近一条提交信息。也可以一步到位git commit --amend -m 新的提交信息注意--amend会改写历史如果这条commit已经push到远程并且是多人协作分支建议不要amend否则别人pull时会遇到“跟远端历史不一致”的麻烦。场景三已经push了想撤销这次的改动这里有两个方向。git reset是把历史指针往后拨等于“假装这次提交没发生过”git revert是新建一个反向提交把改动抵消掉。区别在于操作对历史的影响适用场景git reset改写历史commit记录消失本地未push的提交或单人分支git revert保留历史新增反向提交已push的提交多人协作分支我的建议是只要分支已经推到远程并且别人也拉下来了无条件用revert。reset虽然痛快但会让其他协作者的仓库跟远程历史分叉后面怎么merge都别扭。回滚到指定历史版本git reset --hard HEAD~2 # 回退两个提交 git revert HEAD # 抵消最近一次提交的改动--hard是危险参数它会丢弃工作区和暂存区的所有修改。执行之前一定要确认自己没有未保存的改动或者先用git stash暂存起来。2.3 提效技巧与常见误操作日常使用里还有几个高频命令值得单独点一下git stash临时保存当前工作区改动让工作区干净。适合“改到一半突然要切分支”的场景。git stash # 暂存改动 git stash list # 查看暂存列表 git stash pop # 恢复最近的暂存改动git log --oneline --graph查看精简提交历史配合--graph能看到分支图比默认的一长串信息直观得多。git diff查看工作区与暂存区的差异。commit前花10秒看一眼改动内容可以省掉“提交了个空文件”的尴尬。git tag为重要版本打标签比如发布节点。线上版本回溯时配合标签比翻commit哈希高效得多。git tag v1.0.0 -m 发布1.0版本 git tag # 查看所有标签 git checkout v1.0.0 # 切换到该版本代码误操作方面我见过的“翻车”集中在两类一类是git add .把不该提交的文件比如本地配置、密钥、临时脚本给带上来了处理办法是提交前git status检查确认或者用.gitignore先排雷另一类是git push前拉了别人的更新结果代码冲突直接傻眼。这类问题后面第3节会展开讲。3. 分支合并与冲突处理分支是Git的真正杀招。它让多人并行开发同一套代码而不互相踩脚。但分支开多了合并时的冲突问题就像房间里的大象绕不开。这节我重点讲合并策略选择、冲突解决流程以及协作规范。3.1 merge还是rebase这是个策略问题合并分支有两条路子git merge和git rebase。git merge把两条分支的开发历史“汇聚”成一个合并提交merge commit。它的历史是“真实”的——保留了所有分支的独立发展脉络。我用一张简单场景来说明你在feature分支提交了3次main分支在这期间被别人提交了2次merge后历史图上会看到一个交汇点feature的3次提交和main的2次提交都清晰可见。git rebase则是“重放”提交把feature分支上相对于main的差异提取出来然后按顺序重新提交到main的尖端之上。结果是历史变成一条直线看起来就像feature是在main的最新代码之上连续开发的。这是它讨喜的地方也是它危险的地方——rebase会改写提交哈希如果这个分支已经push到远程并被别人拉过rebase后再次push会直接跟远程历史起沖突。实际操作经验我给自己定了几条规矩个人分支、未推送过的分支用rebase让历史更干净。多人协作分支、已推送且被review过的分支用merge不要rebase。合入主干分支前先在自己本地rebase一次把可能的冲突在本地方掉再merge到main上。这个模式的精髓在于“远端主干始终干净个人分支尽量追上最新”。3.2 冲突解决现场实录冲突是合并时躲不开的环节。很多新手遇到conflict就慌其实冲突的本质很简单两个分支改动了同一个文件的同一块区域Git不知道怎么自动处理就把决定权交给你。先演示一次典型流程。假设当前在feature/login分支上开发main分支有新提交你想把main合进来git checkout feature/login git merge main如果冲突发生Git会提示CONFLICT (content)并告诉你哪些文件有冲突。这时用git status列出冲突文件。打开一个文件你会看到 HEAD 你的当前分支代码 main分支的代码 main HEAD到之间是当前分支的内容到 main之间是待合并分支的内容。解决办法是手动编辑把不需要的标记行删掉最终保留的代码就是合并后的结果。我这里给出一个非常实用的冲突处理顺序git status看冲突文件清单。逐个打开冲突文件理解双方意图。这里强烈建议不要偷懒用git checkout --ours或--theirs直接选边除非你很清楚另一边的改动是什么。直接选边经常把别人辛苦写的逻辑覆盖掉。解决完所有冲突文件后git add每个解决过的文件。执行git commit完成合并。不需要手动写messageGit会生成默认的合并提交信息。对于“怎么快速定位冲突位置”这个刚需现代编辑器已经给出很好的方案。VS Code会在冲突处显示高亮和一个“Accept Incoming/Current”按钮JetBrains系IDE有图形化的Resolve Conflict面板能直观看到两边差异。我个人的习惯是复杂的冲突用IDE的可视化面板简单的到文件里手动改。3.3 保护分支与协作规范跟多人协作相关的分支规范我总结下来三条最有用主干分支设为受保护分支protected branch。GitHub/GitLab上可以设置不允许直接push到main必须通过Pull Request/Merge Request来合入。这个机制强制要求代码评审能挡掉大量低级错误。分支命名带前缀feature/xxx新功能、fix/xxx修bug、docs/xxx文档改动。目录结构一清晰后面用git branch --list origin/*或者代码托管平台过滤分支时非常省事。每次开始新功能前先git pull拉一下main确保自己的分支基于最新代码。如果基于陈旧代码开发后面合并时冲突面积会大得惊人。4. SSH认证失败的完整排查流程SSH认证失败是Git使用中的高频翻车点。报错通常长这样Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.这行提示说人话就是远端没认出你是老几。最常见的场景是本地还没配置SSH密钥或者公钥没添加到GitHub/GitLab上。下面我按排查顺序把踩过的坑一一拆开。4.1 排查前的三个前置确认遇到认证失败先别急着重新生成密钥把三个前置问题过一遍远端地址是不是SSH格式如果你用的是https://github.com/xxx/yyy.git这种HTTPS地址那压根不涉及SSH认证报错格式也不同。要确认走的是SSH远端地址应该是gitgithub.com:xxx/yyy.git。本机是否已存在密钥执行ls ~/.ssh/看有没有id_rsa、id_ed25519这类文件。如果已经存在说明以前生成过可能只是没添加到平台账号。远端平台选对没GitHub、GitLab、Gitee各自的SSH公钥添加入口不一样把公钥加错了平台等价于拿着A家的钥匙开B家的锁自然进不去。4.2 从头到尾的SSH配置实操如果你确认要重新生成密钥按下面步骤走ssh-keygen -t ed25519 -C your_emailexample.com这里我推荐ed25519算法。相比老一代RSA它的密钥长度更短、安全性更好而且在GitHub等平台的兼容性完全没问题。唯一要注意的是某些老旧的内部Git服务器可能不支持ed25519这时才需要用rsa -b 4096。回车之后会问保存位置和密码。保存位置直接默认即可密码passphrase可以留空也可以设置。我建议本地开发机可以直接留空因为每次push输密码挺影响效率。如果是公司配发的电脑或公用机器设置一个passphrase更稳妥否则任何人拿到这台机器就相当于拿到了你所有代码仓的钥匙。生成后打印公钥cat ~/.ssh/id_ed25519.pub把输出的一整行内容复制。然后在GitHub打开Settings - SSH and GPG keys - New SSH key粘贴保存。验证连接ssh -T gitgithub.com第一次连接会提示Are you sure you want to continue connecting (yes/no)?输入yes。如果配置成功会看到类似Hi username! Youve successfully authenticated, but GitHub does not provide shell access.这句话的意思是SSH认证已经通过GitHub只是不允许你用SSH登录shell环境这是正常现象。看到这句话认证这块就算彻底通了。4.3 排查中容易忽略的几个细节如果密钥生成、公钥添加都没问题但还是认证失败问题大概率出在下面几个地方多账号场景下的SSH配置冲突。你同时使用GitHub和个人公司的GitLab本机只有一份默认密钥GitHub配置成功后公司仓库连不上。这种时候要创建~/.ssh/config文件按域名区分不同密钥Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_gitlab然后分别生成两个不同的密钥文件添加到对应的平台即可。ssh-agent没有加载密钥。Windows的Git Bash有时打开新会话后ssh-agent没启动虽然私钥文件存在但认证代理没加载。可以手动执行eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519known_hosts记录过期或异常。当你更换过密钥、或者服务器地址复用的情况下SSH可能因为known_hosts里的旧指纹不匹配而拒连。此时删除对应host的known_hosts条目即可。ssh-keygen -R github.com然后重新ssh -T gitgithub.com。5. 日常协作里那些文档不写的潜规则Git的官方文档把命令讲得很清楚但真实项目里那些约定俗成的协作方式往往才是提高效率的关键。这一节聊几个我觉得最值得重视的实践经验。第一个是关于commit message的写法。我个人非常推荐Conventional Commits风格即提交信息带类型前缀feat: 新增用户登录接口 fix: 修复登录态过期报错问题 docs: 更新接口文档 refactor: 重构用户校验逻辑 chore: 升级依赖版本这种格式的直观好处体现在代码审查和回溯时——扫一眼log就能知道一次历史提交是新增、修复还是重构配合git log --oneline看项目脉络尤其舒服。第二个是合理利用.gitignore。很多项目在初始化后没有及时维护这个文件导致本地配置、编译输出、依赖目录等被反复提交每次git status看得到一堆无关改动。项目初始化时就把该忽略的规则铺好后面省心非常多。我常用的模板大致长这样# 依赖 node_modules/ vendor/ # 编译输出 dist/ build/ # 本地配置 .env.local *.local # 日志 *.log # IDE配置 .idea/ .vscode/第三点是pull之前先stash或commit。这是个非常实在的血泪经验。很多人在两个分支间穿梭时工作区堆了半截改动没提交然后直接git pull结果立刻撞上“Your local changes would be overwritten by merge”报错。正确姿势是切换分支前如果没有提交的底账先git stash暂存切到目标分支处理完事情再git stash pop恢复。这个习惯养成后分支切换会流畅很多。第四点是关于远端同步的频率。在协作项目里我的习惯是每天开始工作前先git pull一次push前再git pull一次。别看这多出来的两次拉取不起眼它能把两天一冲突变成两天一顺滑。很多人push前不拉远端一push就撞到“远端有新提交”的提示然后被迫处理rebase或merge完全是本不必要的麻烦。写在最后Git操作的价值不在于背下多少命令而在于建立起一套适合自己的工作流环境配置、日常操作、分支策略、认证管理每个环节都通顺了版本管理才能真正成为开发的助力而不是负担。我最初也走过弯路现在回头看最受益的是把上面提到的几个习惯坚持了下来——按需提交、push前先pull、分支命名规范、SSH配置维护。这些都不是什么高深技巧恰恰是它们把日常Git操作变成了一件不用动脑就能做对的事。希望这篇总结也能帮你少踩几个坑。