上一篇文章我们聊了 Git 的安装、环境变量配置以及把本地仓库关联到远程仓库的基础流程。文章发出来之后陆续有朋友反馈装是装好了git --version也能跑通可真到了日常开发里碰到分支合并、冲突解决、代码回滚还是经常一头雾水还有人卡在“无法识别 git 命令”、克隆代码报证书错误这些坑里出不来。这篇 git操作二就把这些高频场景挨个捋一遍内容主线是每天都要用到的 add/commit/push 三件套分支管理和 merge/rebase远程仓库协作与免密配置提交规范与效率提升最后收尾在几类最常见的报错排查上。说明一下我自己平时主要用的是 Git Bash配合 VS Code 的 Git 面板和命令行混着来所以下面大部分操作在 Git Bash 和终端下都会演示到Windows 和 macOS 的命令基本通用。如果你习惯用 TortoiseGit小乌龟这类图形工具原理也是一样的只是入口不同。这篇文章不讲太深太散的底层原理专门针对“日常真的会用到的 Git 操作”来写帮你少踩几个坑。1. 日常高频命令组合add、commit、push 的正确姿势1.1 工作区、暂存区、版本库先搞清楚这三个概念很多新手把git add .和git commit当成一个不可分割的流程闭着眼睛一路敲到底其实不理解暂存区的存在后面搞冲突、回滚、amend 的时候会非常痛苦。我用一个生活化的类比来解释工作区是你手里的草稿纸改动都在上面暂存区是挑拣好的待打印清单你已经确认了哪些内容要进入下一次存档版本库是已经装订好的存档册每次 commit 就相当于往存档册里固定了一页。那为什么中间要加一道暂存因为实际开发里一个文件里可能改了好几处逻辑而你想要把它们拆成两个独立的提交。比如你正在写订单导出功能顺手把登录页的一个按钮样式修了那你完全可以git add order_export.py提交一版“feat: 增加订单导出功能”再git add login_button.css提交一版“style: 修复登录页按钮样式”。更进一步如果你嫌git add 文件名粒度还是太大可以用git add -p按 hunk代码块选择暂存只把某一个逻辑片段加进去。这个技巧在代码审查严格的团队里非常实用能让每个 commit 都像一篇逻辑清晰的小作文。配合git status可以看到三种文件状态Untracked 表示新文件还没被 Git 跟踪Modified 表示已跟踪文件被改动但还没暂存Staged 表示已经git add过但还没 commit。再配合三个 diff 命令就能精准掌握改动情况git diff查看工作区里未暂存的改动git diff --cached查看已暂存但还没提交的改动git diff HEAD查看从最近一次提交到现在所有改动。这三个命令覆盖了日常 80% 的“我到底改了什么”的需求比对着文件一行行肉眼检查靠谱得多。1.2 提交信息别乱写commit 是写给未来的自己看的git commit -m 修改这种提交信息短期你爽了两周后回头看git log --oneline完全不知道当初动了哪些东西。比较通用的提交信息格式是type(scope): subject例如feat(user): add login api、fix(cart): fix total price calculation。其中 type 常见的有 feat新功能、fix修复 bug、docs文档、style格式、refactor重构、test测试、chore构建或依赖scope 是模块名或影响范围subject 用简短一句话说清楚做了什么尽量控制在 50 个字符以内。如果你的提交信息写错了或者漏掉了一个文件可以用git commit --amend修改最近一次提交。注意 amend 会重新生成提交对象如果该分支已经推送到远程并且别人也在用就不要再 amend 了否则会导致历史分叉同事一 pull 就是一脸问号。如果只是本地还没 push放心用就行。另外git commit -am msg可以跳过git add直接提交已跟踪文件的修改但新文件不会被包含所以别指望它一步到位。1.3 push 不是万能的fetch 和 pull 的区别要搞清楚很多人习惯一条git pull拉取最新代码其实 pull 是 fetch merge 的合成命令。fetch 只会把远程更新下载到本地仓库的远程跟踪分支比如origin/main不会动你当前的工作区pull 则会在 fetch 之后自动合并或 rebase 到当前分支。搞清楚这点很重要如果你工作区有未提交的改动直接 pull 可能因为自动合并而冲突而先 fetch 看一眼远程到底多了哪些提交再决定是 merge 还是 rebase往往更稳。git push之前也最好确认本地和远程没有分叉。如果本地落后远程好几个 commit 而直接 push远端会拒绝提示non-fast-forward。这时正确的做法是先 pull 远程代码解决冲突后再 push。团队协作中尽量做到小步提交、频繁同步别在本地攒一大堆改动再一次性推上去不然一旦冲突排查范围会指数级扩大。2. 分支管理与合并团队协作的核心战场2.1 分支命名和切换feature 分支怎么玩才不乱团队里比较常见的规范是保持主干分支稳定比如 main 或 master开发功能时从主干切出feature/xxx分支修复线上问题用hotfix/xxx发布版本用release/xxx。分支命名要能表达意图feature/order-export比dev这种泛泛的名字清晰得多看仓库分支列表就能知道每根分支在干嘛。创建和切换分支的命令旧版习惯用git branch feature/xxx创建git checkout feature/xxx切换新版 Git 推荐用git switch -c feature/xxx一步完成创建并切换语义也更清楚。本地分支要推到远程执行git push -u origin feature/xxx-u会建立跟踪关系之后直接git push或git pull就能自动匹配远程分支。删除分支用git branch -d feature/xxx如果分支还没合并需要-D强制删除但一定要确认代码已经合并或者备份否则数据就不见了。2.2 merge 和 rebase什么时候选哪个别搞混合并分支最常用的方式是git merge。如果目标分支比当前分支新合并时可能产生一个 merge commit把两侧历史拼在一起。另一种方式git rebase则是把当前分支的提交“重放”到目标分支的最新提交之后让历史变成一条直线。我常用一个场景说明你和同事基于 main 各自开发同事先合并了 A 提交你本地有 B 和 C 提交。merge 的做法是生成一个“汇合点”提交历史呈分叉再合并rebase 的做法是把 B、C 摘下来依次放到 A 后面变成 main - A - B - C 的直线历史。那实际怎么选如果只是自己本地整理提交rebase 很合适能保持历史干净如果要合并到公共分支建议用 merge因为 rebase 会重写提交编号可能导致别人的本地分支和远程不同步。公共分支上的 rebase 被推翻之后那些提交找回来会非常费劲。我的经验是个人分支随便 rebase公共分支只用 merge这是团队协作最稳妥的策略。另外git pull --rebase在某些场景下更好用比如你本地有未推送的提交而远程已经有别人推的新提交时rebase 能避免产生无意义的 merge commit。2.3 冲突解决看到 别慌按这个流程走合并和 rebase 时最怕的是冲突其实冲突的原因是两个人改了同一个文件的同一块区域Git 没办法自动判断该保留哪份改动。冲突标记大概长这样 HEAD 你当前分支的代码 被合并进来的代码 feature/xxx解决方法其实很简单打开冲突文件手动决定保留哪一边或者两边都保留然后把、、这些标记全部删除接着git add该文件再git commit完成合并。如果你用 VS Code它会用不同颜色高亮当前分支和传入分支的改动点一下就能选择IDEA 也自带图形化合并工具左中右三栏对比复杂冲突反而更直观。减少冲突的关键是“小步提交 及时同步”一次改动范围别太大多和共享分支同步。真冲突了也别慌按文件逐个解决解决完跑一遍编译和测试再提交。注意如果你用的是 rebase 过程中出现冲突解决完不要 git commit而是git rebase --continue否则会脱离 rebase 流程如果实在解决不下去git rebase --abort可以回到 rebase 之前的状态至少能保证不把局面进一步搞乱。3. 远程仓库操作与免密配置3.1 clone 和 remote上传代码到远程仓库的正确流程这一节对应很多人卡住的“git上传代码到仓库”。公司在 GitLab 或代码托管平台建好空仓库后一般会给出 HTTPS 和 SSH 两种地址。如果你只是临时拉取代码HTTPS 最省事如果打算长期协作SSH 更推荐因为免密而且不容易被凭证失效打断。git clone https://gitlab.example.com/group/project.git cd project如果本地已经有项目需要关联到远程仓库可以这样git init git remote add origin https://gitlab.example.com/group/project.git git add . git commit -m init project git push -u origin main远程仓库地址可以通过git remote -v查看。如果后续仓库地址变了用git remote set-url origin new-url修改不用重新 clone。这里提醒一句别在一个 Git 仓库里再嵌套git init容易出现内外两层仓库导致提交到错误的上游这类问题排查起来特别绕。3.2 SSH Key 配置一次配置以后都不输密码SSH 免密的核心是生成一对密钥私钥留在本地~/.ssh/公钥放到 GitLab 或 GitHub 账号里。生成方式ssh-keygen -t rsa -b 4096 -C your_emailexample.com一路回车即可默认生成~/.ssh/id_rsa和~/.ssh/id_rsa.pub。然后把id_rsa.pub的内容完整复制到平台的 SSH Keys 设置页面保存后执行测试ssh -T gitgitlab.example.com看到Welcome to GitLab, username这类提示就说明 SSH 配置成功后面 clone 的时候选 SSH 地址就不会再要求输密码。如果你同时用 GitHub 和公司的 GitLab多账号场景下可以在~/.ssh/config里配置不同的 Host指定不同的密钥文件Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github Host gitlab.example.com HostName gitlab.example.com User git IdentityFile ~/.ssh/id_rsa_work配好后不同域名走不同私钥互不干扰。如果遇到Permission denied (publickey)先ssh-add -l看私钥是否被加载再用ssh -vT githost查看调试输出重点确认它使用的是哪个 key 文件。绝大多数 SSH 免密问题都是公钥没复制全或者私钥路径不对导致的。3.3 Windows 下的另外一种免密方式凭证管理器如果不愿意折腾 SSHWindows 上最常见的免密方式是使用 Git 自带的凭证管理器。安装 Git for Windows 时选默认选项第一次 clone 或 push 输入账号密码后系统凭据管理器会自动记住后续操作基本不会再弹窗。如果遇到弹窗特别频繁或者希望手动强制启用可以执行git config --global credential.helper manager这个方式会把凭据加密存储到 Windows 的凭据管理器里比较安全。至于另一种credential.helper store它会以明文把用户名密码写到~/.git-credentials一旦文件泄露等于账号密码白送我强烈不建议在生产环境使用。还有一点当你看到“登录失败 / token 失效”时去平台的 Access Token 页面重新生成一个新的再重新 clone 或更新远程地址里的凭证即可不用卸载重装 Git。4. 提交规范、配置优化与 IDE 集成4.1 一份能落地的 Git 提交规范前面提过type(scope): subject格式这里再展开说说。约定式提交是目前比较通用的规范type 的类型和适用场景用表格列一下type使用场景feat新功能fix修复 bugdocs文档变更style格式调整不影响代码逻辑refactor重构代码不改变外部行为test添加或修改测试chore构建、依赖等杂项变更提交信息最好写成祈使句、小写开头比如fix(login): handle token expiration而不是Fixed login bug.。团队可以借助 husky 和 commitlint 在提交时自动校验格式不合规的直接拒绝提交减少人工 review 的成本。与此同时提交粒度也要控制好一个 commit 只做一件事。用git log --oneline --graph查看提交历史时如果每个 commit 都能看懂说明规范基本到位了要是看到一堆“update”“改一下”后续回溯问题就只能靠猜。4.2 全局配置与常用 alias省下重复敲命令的时间Git 的基本身份配置是必须的否则 commit 会提示你设置 user.name 和 user.emailgit config --global user.name Your Name git config --global user.email your_emailexample.com配置项会写在~/.gitconfig用git config --global --list可以查看当前所有全局配置。我比较推荐给高频命令设置 alias能省不少时间git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status git config --global alias.lg log --oneline --graph --all --decorate设置之后git st就是git statusgit lg就是一眼看清分支和提交关系的提交图。别小看这些 alias高频命令每天敲几十次少几个字母累积起来很可观。还有一个实用的全局配置是core.autocrlf在 Windows 上建议设成true提交时自动把 CRLF 转成 LF能明显减少跨平台换行符导致的 diff 混乱。4.3 用 VS Code / Cursor 集成 Git图形化也能完成大部分操作对于不习惯命令行的朋友VS Code 和 Cursor 都内置了 Git 面板。左侧源代码管理图标点开后可以看到所有改动文件旁边的 M 表示修改U 表示新增D 表示删除选中文件可以查看 diff点击文件右侧的加号可以暂存改动提交框里写好消息直接点提交按钮就行。分支切换、推送、拉取也都有图形化入口完全可以不用打开 Git Bash。如果觉得原生面板不够强大可以装 GitLens 插件它能显示每一行代码的提交作者、提交时间和 commit 信息看历史时特别直观团队协作的时候“这行代码是谁改的、为什么改”一目了然。还有 TortoiseGit小乌龟在 Windows 文件管理器中右键就能完成大部分 Git 操作和命令行原理一致只是换了入口。我的建议是熟悉一套图形工具的同时还是要把常用命令练熟因为排查问题、写自动化脚本、看文档的时候命令行永远是最通用的表达方式。5. 疑难杂症排查实录报错之后先别重装按这个思路查5.1 “无法将‘git’项识别为 cmdlet” 与环境变量问题Windows 下最常见的报错就是 Git 命令找不到表现为 CMD 提示“git 不是内部或外部命令”或者 PowerShell 提示git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。原因是 Git 的可执行文件目录没有加入 PATH或者安装 Git 时没有勾选 “Add to PATH”。解决办法分三步第一步确认 Git 是否安装成功能打开开始菜单里的 “Git Bash” 就说明安装没问题第二步找到 git.exe 所在目录一般是C:\Program Files\Git\bin和C:\Program Files\Git\cmd第三步打开“系统属性 - 环境变量”把上述路径追加到系统环境变量 Path 中保存后重开终端再试。这里有个细节改完环境变量后最好完全关闭当前终端再重新打开因为终端启动时会读取 PATH旧窗口不一定能感知新配置。如果是公司电脑没有修改系统环境变量的权限也可以在 PowerShell 里临时执行$env:Path ;C:\Program Files\Git\cmd但这样只对当前窗口有效重启终端后失效。最彻底的办法还是重新运行 Git 安装包安装向导里选上 Add to PATH让安装程序自动配置好。5.2 SSL 证书报错error setting certificate file 的正确处理很多人在内网拉代码时会遇到类似这种报错fatal: unable to access https://gitlab.example.com/group/project.git: error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt这通常不是网络问题而是 Git 在本地找不到或无法读取根证书文件。常见原因有两个一是 Git for Windows 安装路径包含中文或特殊字符导致证书路径解析失败二是全局配置里设置了错误的http.sslCAInfo。我遇到过的几次基本都是全局配置指向了一个不存在的证书路径。可以先执行git config --global --list查看有没有http.sslca相关配置如果配置的路径不对或者文件不存在把它删掉或用正确的证书路径覆盖。另一个稳妥方案是重装 Git for Windows安装目录尽量选纯英文路径比如D:\Program Files\Git。如果只是本地临时排查执行git config --global http.sslVerify false可以绕过证书校验但我建议只在个人测试环境用不要在生产环境这么干。一旦关闭证书校验HTTPS 的防篡改、防冒充能力就形同虚设中间人攻击和代码泄露风险会陡增。真正该做的是把证书链配置正确而不是一关了之。5.3 clone 失败与登录失败的通用排查思路git clone失败可以按“地址对不对 - 网络通不通 - 凭证有没有 - 权限够不够”的顺序排查。地址对不对就是检查 URL 是否拼接正确是否缺少组名或项目名网络通不通可以用浏览器访问一下远端仓库地址看能不能打开凭证有没有通常对应Authentication failed权限够不够则经常提示Access denied或repository not found。很多内网托管平台还会出现一个很典型的错误“login failed. check api token or gitlab version”。这大概率指向两个方向一是账号 Token 过期或没有权限去平台重新生成 Access Token 再试二是 GitLab 服务器版本太旧和当前 Git 客户端使用的认证协议不兼容这种情况一般要更新 Git 版本或者找平台管理员确认 API 兼容性。还有一个在 IDE 里经常看到的命令git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks ...这条其实是 IDEA 这类 IDE 在调用 Git 时注入的临时参数-c表示覆盖某个配置项--no-optional-locks是让 Git 不自动获取可选锁避免刷新状态时卡住。看到它出现不代表出故障只是 IDE 在后台帮你执行 Git 命令不用紧张。5.4 安全提醒别把 .git 目录泄露到线上排查“git目录泄露”其实是 Web 安全里经常出现的漏洞场景。如果网站部署目录里保留了完整的.git文件夹攻击者用工具能把提交历史、源码配置甚至数据库连接串全部下载下来。对开发者来说重点不是“如何下载”而是“如何防止泄露”生产环境部署时确保.git目录不被打包上传敏感文件提前用.gitignore忽略比如.env、*.key、*.pem、config/secret.yml建仓库前检查是否把node_modules、target、dist等编译产物误提交进去一旦发现仓库里不小心提交了密钥不要只删除文件再提交因为密钥已经存在历史记录里需要清理历史或重置仓库必要时请平台管理员介入。这些不是危言耸听公司内部安全审计经常能扫出一堆仓库里裸奔的 token。养成从第一天写.gitignore的习惯能避免掉无数后续麻烦。我个人在实际操作中最深的体会是Git 这类工具光靠背命令是记不牢的必须放进真实项目里反复用。每次报错也别急着重装先把错误信息拆解成环境、网络、凭证、权限四个维度按流程排查一遍经验值涨得很快。这篇 git操作二偏实战如果你在实践里遇到过什么诡异的报错也欢迎分享没准下一篇就跑不掉了。