简介Git_Extract.zip 是一份面向安全工程师、开发人员及CTF选手的Git泄露检测与恢复工具包专注处理Web服务器上意外暴露的.git目录帮助用户快速扫描、提取提交历史和文件内容评估代码泄露风险并制定应对方案。压缩包共10个文件包含5个Python脚本、4个pyc模块和1个Markdown说明文档整体约13KB其中Python脚本覆盖入口调度、Git对象解析与索引恢复pyc文件可加速调用说明文档提供完整使用指南。已有940人学习下载适合需要了解Git源码泄露原理、练习git目录还原或从事Web安全应急响应的学习者。通过该工具读者不仅能获得一套可运行的泄露检测脚本还能结合具体源码理解Git对象存储、索引解析等底层机制并将相关方法迁移到其他安全检测场景中切实提升对源码泄露风险的识别与处置能力。1. Git 不是 SVN 升级版先搞定本地仓库思维再谈命令与配置很多人第一次碰 Git心里想的是“这不就是 SVN 升级版吗”。这个念头会在第一次正经干活时付出代价本地 commit 个半成品顺手 push 上去第二天构建就红了一片。SVN 是中央仓库加工作副本Git 是分布式版本控制每台开发机都有完整历史commit、分支、回滚本质上是本地私密操作只有 push 那一刻才对外可见。心智模型不对命令背再多也翻车。这份 Git_Extract.zip 拆开看是一套 Git 上手素材解压即用的 Windows 环境、命令速记文件以及把 fatal: not a git repository、SSH 认证失败这类报错单独整理的排障清单。适合刚配完电脑还没理顺 user.name/email/Gitee 公钥的人也适合每天在 IDEA 里被分支冲突搞到头大的后端。这篇笔记按安装、配置、命令、排障这条链路走每条命令都给能直接抄的写法顺带把资源里最值得注意的坑提前标出来。2. 从下载到免密登录Git 安装配置与 SSH 密钥一次讲清2.1 下载安装包版本选择、国内镜像与“解压即用”先解决工具从哪来的问题。官网下载安装程序是最常规的路子但现实中不少开发机没有管理员权限或者公司电脑装软件要走流程等审批下来半天都过去了。Git_Extract.zip 里带的是解压版环境从一个已有安装拷出来、去掉安装程序的形态解压到任意目录把 bin 目录加进 PATH 就能用。我一般优先用解压版卸载也简单直接删目录不留注册表残骸。下载渠道上国内网络环境下官网速度不稳定是常态常见做法是从清华 TUNA、阿里云这类镜像站拉 Git for Windows 的压缩包文件名和版本号与官网一致校验 SHA-256 对得上就能放心用。# 假设解压到了 D:\tools\Git D:\tools\Git\bin\git.exe --version # 在 Git Bash 里验证同样可行git bash 本身也在这个目录下 git --version逻辑说明Git 的核心是一堆可执行文件集中在 bin 目录。Windows 命令行默认不认识 git要么写全路径调用要么把 bin 加进 PATH。加 PATH 的常见做法是“此电脑 → 属性 → 高级系统设置 → 环境变量 → Path → 新建”填 D:\tools\Git\bin重开终端就生效。Git Bash 是随 Git 一起提供的模拟器解压版里同样自带日常在 Windows 上敲 Linux 风格命令就靠它。参数说明版本号不用追新但别太老。2.23 之前的老版本对 ed25519 公钥算法的支持不完整Gitee 或公司 GitLab 换成新版密钥时会直接拒绝连接。另一个隐藏较深的坑是换行符选项如果仓库从 Windows 拷到 Linux出现“明明没改但 diff 显示全文件改动”多半是 CRLF 和 LF 没统一。常见做法是 checkout 时保持原样、commit 时用 LF配合 .gitattributes 兜底不要手工翻“自动转换”开关。2.2 全局配置user.name 与 user.email 决定提交记录归属装上 Git 之后第一件事不是急着 clone而是把身份信息写进全局配置。这一步经常被当成无关紧要的小事跳过去结果第一次 commit 时 Git 直接拒绝或者提交记录里出现一个随机生成的“Administrator”名字后面看日志根本不知道谁改的。团队里一旦混入这种无名提交追责和统计工作量都变成一件头疼事。# 设置提交者姓名和邮箱邮箱要填真实常用地址 git config --global user.name 你的名字 git config --global user.email youexample.com # 查看当前生效的全部配置 git config --list # 只需要看某一项值时 git config user.name逻辑说明commit 时 Git 会把 author 信息写进提交对象里这是多人协作时追溯“谁改的”的唯一依据。Gitee、GitLab、GitHub 都用 email 把提交关联到账号头像邮箱设置得与账号不一致提交记录会变成另一个身份哪怕名字一样也不会关联。我有过同事把 email 拼错一个字母整个月提交都显示成两个作者复盘看板时全是碎片最后只能一个个批量改历史。参数说明配置分三层system 是机器级global 是当前系统用户local 是单个仓库。--global 影响本机所有仓库想针对某个仓库例外进仓库目录去掉 --global 再设置一次即可。git config --list 按优先级展开同一项出现多次说明不同层级都有值最终生效的是 local global system。排查配置问题时先看列表里最后出现的值那才是真实生效值。2.3 SSH 密钥配置给 Gitee 设置免密登录这是“git 配置账号密码”这条路线上卡住最多人的环节。每次 push 都弹账号密码框敲完登录密码还要再输一遍用户名一天重复几十次耐心很快耗尽。SSH 免密原理不复杂本地生成一对公私钥公钥上传到 Gitee 或 GitHub之后推送走 SSH 协议远端验证通过就直接放行。# 生成 ed25519 格式密钥-C 只是备注用来区分是哪台机器 ssh-keygen -t ed25519 -C youexample.com # 默认生成到 ~/.ssh/id_ed25519私钥和 id_ed25519.pub公钥 # 查看公钥内容复制整行 cat ~/.ssh/id_ed25519.pub逻辑说明生成过程会问 passphrase我一般直接回车跳过如果所在环境安全要求高可以设置一个之后用 ssh-agent 缓存不用每次输入。公钥可以公开私钥必须留在本机粘贴的时候认准 .pub 结尾的文件千万别把不带 .pub 的私钥内容贴到 Gitee 上。复制后打开 Gitee → 头像菜单 → 设置 → SSH 公钥粘贴保存即可。# 测试认证是否通过 ssh -T gitgitee.com参数说明ed25519 是目前主流的密钥算法比 RSA 2048 更短更快如果目标是特别老的内网 GitLab可能不认识 ed25519回退方案是ssh-keygen -t rsa -b 4096。测试输出Hi xxx! Youve successfully authenticated就算通了。看到Permission denied (publickey)不要急着重新生成密钥先按第 4 章的排查步骤走一遍大部分问题不在密钥本身而在加载和地址上。2.4 图形工具接管 Git 的常见坑IDEA 与 VSCode 的凭据问题命令行跑通切到 IDE 又出幺蛾子是高频剧情。IDEA 的 Git 面板和 VSCode 的源码管理底层调用的都是同一套 Git 命令但凭据处理路径不一样IDEA 用自己的内置凭据存储VSCode 倾向于 Windows 凭据管理器。这就导致一个诡异场景——终端 push 正常IDEA 里却一直报认证失败。原因多半是 IDE 里配置的 Git 可执行路径指向了另一个版本两边的配置和凭据井水不犯河水。常见做法是先确认 IDE 里 Git 路径IDEA 打开 File → Settings → Version Control → Git把 Path to Git executable 换成解压版实际路径VSCode 在 settings.json 里设置 git.path。之后如果还弹旧密码多半是凭据管理器里留着过期记录按 4.4 节的 cmdkey 清掉再试。另一个翻车点是换了电脑克隆仓库时用的还是 HTTPS 地址SSH 配置得再完美也碰不到 SSH 认证记得先看git remote -v输出的协议头。3. 高频命令实战分支合并、commit --amend 与 worktree 的正确边界3.1 分支操作骨架从创建到合并先弄懂底层含义分支是 Git 里用得最多也最容易动作变形的地方。日常开发中我习惯把分支当临时工作台功能没做完的分支不急着合回主干改动都留在分支里随时可以重新整理。创建分支的现代写法是 git switch语义比 checkout 更清晰旧版没有这个命令就用 checkout -b。# 基于当前分支创建并切换到新分支 git switch -c feature/payment # 如果目标分支已存在只想切过去 git switch feature/payment # 查看本地分支与远端追踪关系 git branch -vv逻辑说明switch -c 的 -c 是 createGit 会基于当前 HEAD 位置拉一个新分支并切换。这里有个容易被忽略的点创建分支前先确认自己站在哪个分支上。新分支基于主干还是基于某个特性分支直接影响后面合并的 diff 范围。从一堆未合入的特性分支上再拉分支最后合并时冲突叠加起来会非常痛苦。合并有两种常见结果Fast-forward 和三路合并。Fast-forward 指目标分支没有新提交Git 直接把指针往前挪历史保持一条直线目标分支有新提交时Git 会生成一个 merge commit 把两边改动拼起来。理解这两种结果看到“Merge branch xxx into main”这种自动提交信息就不会慌也能明白为什么有时候合并历史是干净的直线有时候是一团分叉。# 切回主干拉取远端最新代码 git switch main git pull origin main # 把功能分支合并进来如果冲突会停在 merge 中间态 git merge feature/payment参数说明pull 相当于 fetch 加 merge 两步。团队约定用 rebase 的改成git pull --rebase origin main。我个人的习惯是主干用 merge保留合并记录完整自己维护的特性分支在合回主干前如果主干更新了用 rebase 把本地补丁重放到最新代码上历史更线性review 也更容易。但这个偏好必须跟团队约定一致别让仓库里 merge 和 rebase 混着来。3.2 用 commit --amend 改写提交用途、写法与边界git commit --amend 是那种“好用但容易炸”的命令。它的作用是重做上一次提交提交信息打错了想改漏提交了一个文件想补进去都可以用 amend 完成而不会新增一个提交节点。搜索结果里“git commit --amend 怎么使用”热度常年不低说明会背命令的人多真正清楚边界的人少。# 只改最近一次提交的信息 git commit --amend -m fix: correct payment amount calculation # 漏了一个文件先加进暂存区再并入上一次提交 git add . git commit --amend --no-edit逻辑说明amend 的本质是用一个新提交对象替换旧提交旧提交从分支引用上“消失”了这就是为什么改完信息后提交哈希会变。如果旧提交已经 push 到共享分支后果是其他人的本地历史里还留着旧提交你强行推送会被远端拒绝必须 force push。而 force push 到共享分支等于在别人眼皮底下重写历史其他人下次 pull 会撞进很尴尬的冲突。所以边界很简单amend 只用于还没有推送出去的提交。注意amend 只适用于还没有推送出去的提交已经推到共享分支的别 amend否则只能用 force push 收拾残局而 force push 对团队协作的杀伤力很大。git log --oneline -n 3如果 amend 之后又想撤销也不是没有办法。git reflog 会记录所有 HEAD 变化找到 amend 之前的提交哈希再 reset 回去。reflog 是本地操作日志只要没做清理就是 Git 世界的后悔药。我把 reflog 当兜底网用但前提是别养成“先干再说”的习惯尤其在共享分支上。3.3 git worktree一个仓库管理多个工作目录上下文切换是开发里最费神的事。你正在 feature/payment 上写代码写到一半线上出了问题要立刻修。如果只有一份工作目录无非两条路git stash 保存现场然后切走或者强迫自己 commit 一个 WIP 提交。这两条路都会打断思路而且切换成本高。git worktree 给出第三条路一个仓库可以关联多份工作目录每份目录对应不同分支互不干扰。# 为某个分支单独开一份工作目录 git worktree add ../page-maintenance feature/payment-maintenance # 列出仓库关联的所有工作目录 git worktree list # 用完后移除这份工作目录 git worktree remove ../page-maintenance逻辑说明worktree 的底层是在仓库里登记多个 working tree它们的 .git 指向同一个对象数据库。注意一个分支只能被一份工作目录检出你在第二份目录里 checkout 同一个分支Git 会直接拒绝。我一般用它双开新旧版本对比或者接 hotfix 时开一份临时目录完全不碰正在开发的功能分支现场上下文切换成本几乎为零。参数说明add 的路径建议放在仓库目录外的同级位置避免嵌套太深被误清理。remove 的前提是目标目录里没有未提交改动否则会被拒绝如果目录里还有零散改动先处理干净再移除。多出来的目录不要手动删除用git worktree prune清理废记录更稳妥避免仓库登记里残留失效路径。3.4 回滚后悔药reset、revert、clean 三兄弟别混用回滚命令是新手心理压力最大的一块因为用错的代价是删代码、丢提交。先给结论已经 push 到共享分支的用 revert纯本地还没推送的用 reset涉及未跟踪文件的用 clean。这三个命令对应三种完全不同的回滚形态用混了才是真正的灾难。# revert用一次新提交反做旧提交历史完整保留 git revert HEAD # reset移动 HEAD 指针让分支“忘记”某些提交 git reset --hard HEAD~1 # clean清理未跟踪文件-n 先预览会删什么-f 才真正执行 git clean -n git clean -fd逻辑说明revert 不删历史它生成一个反向提交来撤销目标提交适用于已经推到远端的代码因为历史完整同事 pull 不会产生冲突。reset 则是把当前分支引用移回去--hard 同时重置工作区和暂存区本地未推送时想彻底抹掉某段历史很顺手改成 --soft 只移动指针改动回到暂存区--mixed 是默认值把改动退回工作区相当于“回到提交前”。参数说明reset --hard 会彻底抹掉指定提交之后的所有改动执行前先 git status 确认没有未保存的东西。clean 的 -d 参数会把目录也一起删默认只处理文件不确定会不会删错先跑git clean -n -d看预览。团队里有同事把 node_modules 当成未跟踪文件被 clean -fd 删掉的先例虽然不是 Git 的锅但那一整天都在重装依赖。从那以后我每次执行 clean 前都强制自己看一遍预览列表。命令是否改写历史适用场景对已推送提交revert否新增提交共享分支撤销代码安全reset --hard是移动分支引用本地提交整理需 force push不建议clean -fd不涉及历史清未跟踪文件与远端无关4. 排障避坑从 fatal: not a git repository 到 SSH 认证失败的完整排查4.1 fatal: not a git repository目录与仓库脱节现象任何 git 命令都直接拒绝执行终端返回fatal: not a git repository (or any of the parent directories): .git。这不是某个命令坏了是所有 git 命令集体失灵连 git status 这种只读操作也跑不了。原因Git 通过寻找 .git 目录来识别仓库。报这个错只有几种可能当前目录根本不是仓库比如在桌面、下载目录直接敲 git 命令仓库的 .git 目录被删除或移走环境变量 GIT_DIR 被手动指到了别的位置。其中第三种最隐蔽实际排障时遇到过一个案例用户 .bashrc 里设置了 GIT_DIR导致终端一开所有 git 命令都指向一个不存在的路径什么都不做就被挡在门外。解决按顺序排查。# 第一步确认自己在哪个目录 pwd # 第二步看当前目录有没有 .git ls -la | grep .git # 第三步检查 GIT_DIR 是否被手动设置过 echo $GIT_DIR如果在某个子目录执行 git 报错而这个子目录确实在仓库内大概率是符号链接或网络映射盘导致 Git 找不到祖先目录。解决方法是 cd 到仓库根目录再操作或者用git -C /path/to/repo status显式指定仓库位置。注意 git -C 和 cd 后再跑 git 的区别前者不改变终端会话的当前目录适合在脚本里定位仓库。4.2 SSH 认证失败密钥、加载、地址三要素必须对上现象git push 返回Permission denied (publickey)有时还伴随一句fatal: Could not read from remote repository。很多人遇到这个报错就重新生成一遍密钥结果新密钥生成完还是同样报错白白浪费时间。原因SSH 认证失败基本逃不开三个地方。第一本地私钥没被 ssh-agent 加载或者私钥路径不是 SSH 默认搜索的位置第二公钥根本没上传到 Gitee或者上传的不是最新那把公钥第三远程地址本身就是 HTTPS 而不是 SSH 协议这种情况密钥配置得再完美也碰不到 SSH 认证。解决不要一上来就重新生成密钥按顺序查。# 看远程地址到底是 SSH 还是 HTTPS git remote -v # 直接测试 SSH 链路是否通 ssh -T gitgitee.com # 确认 ssh-agent 是否持有私钥 ssh-add -l # 如果没有手动加载私钥 ssh-add ~/.ssh/id_ed25519参数说明如果 ssh -T 输出的是Hi username!说明链路没问题问题在仓库地址把 remote 改成gitgitee.com:user/repo.git这种 SSH 格式。如果输出没有 Hi 而是报错继续看 ssh-add -l 的列表里有没有私钥没有就 ssh-add 加载。还有一层容易被忽略的是 .ssh 目录权限Windows 下不明显Linux 下私钥文件权限如果太宽松SSH 会直接拒用执行chmod 600 ~/.ssh/id_ed25519恢复私钥权限即可。4.3 分支合并冲突冲突标记别怕本质是一个文本问题现象git merge 或 git pull 之后Git 没有直接完成合并而是停在特殊状态打印Automatic merge failed; fix conflicts and then commit the result.。打开冲突文件满屏和看着吓人实际就是文本标记。原因两个分支改动了同一处代码Git 无法判断哪一方才是“正确”的只能把这个决定交给人。冲突不是 Git 坏了是它足够诚实机器不敢替你做的决定就会留给你处理。建立这个认知心态就不会崩。解决打开冲突文件结构是这样的。 HEAD 这是当前分支里这段代码的样子 这是被合并分支里这段代码的样子 feature/payment选择保留哪边还是两边都要直接编辑文件把标记行删掉留下想要的版本。然后执行# 标记为已解决加入暂存区 git add src/payment/service.js # 确认所有冲突都已解决 git status # 提交合并结果 git commit参数说明合并中间态的 HEAD 代表当前所在分支后面跟的是被合并分支名。用 IDEA 或 VSCode 的可视化工具点“接受当前/接受传入”底层就是替你做了编辑并删标记的动作没有任何黑魔法。解决冲突后别急着 commit先跑一遍构建或相关单测因为 Git 的合并结果可能把两个分支的逻辑拼出语义冲突比如变量被删了但另一个文件还在引用这种编译级错误 Git 不会拦你。4.4 git 清除账号密码Windows 凭据残留与明文地址现象换完密码或切换账号后git push 仍然反复报Authentication failed无论重新输入多少次都没用或者输入的是新密码终端却像一直在验证旧凭据。常见于用 HTTPS 方式克隆的仓库。原因Windows 凭据管理器里保存着这条仓库地址的旧用户名和旧密码Git 每次认证优先用本地凭据不弹框不询问导致改完密码还是报错。另一种更极端的情况是 remote URL 里直接写了账号密码比如https://user:passwordgitee.com/user/repo.git这种地址一旦泄露就是实打实的安全隐患。解决先看远程地址再清凭据。# 第一步看 remote -v 输出的地址里有没有账号密码 git remote -v # 第二步清掉 Windows 凭据管理器里的旧凭据 # 先列出匹配项再删除 cmdkey /list | findstr gitee cmdkey /delete:git:https://gitee.com参数说明cmdkey /list 会把凭据管理器里匹配 gitee 的条目列出来/delete 的完整参数要跟列出的目标名一致否则删不到。删除后下次 push 会重新弹框输入新密码就正常了。如果 remote 地址里能看到用户名或密码用下面的命令替换成干净地址git remote set-url origin https://gitee.com/yourname/yourrepo.git我一般还多走一步确认远程仓库支持 SSH 后直接把 HTTPS 地址换成 SSH 地址这样既免密也不再有密码残留和过期问题。这条经验在处理公司内网 GitLab 时同样适用内网换密码的频率往往更高。5. 一套可验证的交付习惯状态检查、暂存改动与回滚预案5.1 开工前先做三次检查status、log、diff代码提交前我固定做三个动作坚持下来之后“提交错文件”“漏提交”“把调试代码推上去”这些事故基本被挡在门外。# 看工作区状态确认哪些文件被改过 git status # 看最近提交历史确认当前 HEAD 在哪 git log --oneline --graph --all -n 10 # 检查差异里有没有空白错误 git diff --checkgit status 解决“我改了什么”git log 解决“我站在哪”git diff --check 查的是提交里混入行尾空格、空行这类不痛不痒但 code review 时会被挑出来的问题。执行顺序我习惯 status 在前因为工作区有遗漏时后面看历史意义不大容易把改动提交到错误的分支上。5.2 中途被打断用 stash 保存半成品工作做到一半必须切换分支又不想为了切分支强行提交半成品 WIPstash 就是专门干这个的# 把当前改动暂存起来工作区恢复干净 git stash push -m wip: payment integration not finished # 查看暂存列表 git stash list # 切到其他分支办完事切回来之后恢复改动 git stash apply # 确认恢复无误后删除这条暂存记录 git stash drop参数说明apply 会把改动恢复到当前工作区但不会自动删除 stash 记录恢复后确认代码没问题再 drop 掉避免列表越来越乱。如果有冲突apply 的表现和 merge 一样按冲突解决流程走就行。另一种更彻底的做法是结合 worktree直接开新目录处理其他分支当前现场完全不打断适合需要同时开工两个任务的场景。5.3 让命令验证成为习惯这套东西光看没用找个临时目录把完整流程跑一遍比读十遍教程都有用mkdir demo cd demo git init echo line1 app.txt git add app.txt git commit -m init git switch -c feature echo line2 app.txt git add . git commit -m feature change git switch main echo line2-main app.txt git add . git commit -m main change git merge feature这里一定会撞出冲突正好把前面避坑章节讲的冲突标记、解决流程、reset 和 revert 全部练一遍。看到冲突别慌编辑、add、commit操作乱了就 reflog 找回。真正的熟练是把这些命令变成肌肉记忆而不是收藏夹里的教程。从那以后我每次 merge 或者 force push 之前都会强制自己先跑一遍 status 和 log把当前所在分支与未提交改动确认清楚再动手。这个习惯帮我挡下了至少三次误操作。希望帮到你。本文还有配套的精品资源点击获取 Git核心实践：本地仓库思维、配置SSH密钥与高频命令排障
简介Git_Extract.zip 是一份面向安全工程师、开发人员及CTF选手的Git泄露检测与恢复工具包专注处理Web服务器上意外暴露的.git目录帮助用户快速扫描、提取提交历史和文件内容评估代码泄露风险并制定应对方案。压缩包共10个文件包含5个Python脚本、4个pyc模块和1个Markdown说明文档整体约13KB其中Python脚本覆盖入口调度、Git对象解析与索引恢复pyc文件可加速调用说明文档提供完整使用指南。已有940人学习下载适合需要了解Git源码泄露原理、练习git目录还原或从事Web安全应急响应的学习者。通过该工具读者不仅能获得一套可运行的泄露检测脚本还能结合具体源码理解Git对象存储、索引解析等底层机制并将相关方法迁移到其他安全检测场景中切实提升对源码泄露风险的识别与处置能力。1. Git 不是 SVN 升级版先搞定本地仓库思维再谈命令与配置很多人第一次碰 Git心里想的是“这不就是 SVN 升级版吗”。这个念头会在第一次正经干活时付出代价本地 commit 个半成品顺手 push 上去第二天构建就红了一片。SVN 是中央仓库加工作副本Git 是分布式版本控制每台开发机都有完整历史commit、分支、回滚本质上是本地私密操作只有 push 那一刻才对外可见。心智模型不对命令背再多也翻车。这份 Git_Extract.zip 拆开看是一套 Git 上手素材解压即用的 Windows 环境、命令速记文件以及把 fatal: not a git repository、SSH 认证失败这类报错单独整理的排障清单。适合刚配完电脑还没理顺 user.name/email/Gitee 公钥的人也适合每天在 IDEA 里被分支冲突搞到头大的后端。这篇笔记按安装、配置、命令、排障这条链路走每条命令都给能直接抄的写法顺带把资源里最值得注意的坑提前标出来。2. 从下载到免密登录Git 安装配置与 SSH 密钥一次讲清2.1 下载安装包版本选择、国内镜像与“解压即用”先解决工具从哪来的问题。官网下载安装程序是最常规的路子但现实中不少开发机没有管理员权限或者公司电脑装软件要走流程等审批下来半天都过去了。Git_Extract.zip 里带的是解压版环境从一个已有安装拷出来、去掉安装程序的形态解压到任意目录把 bin 目录加进 PATH 就能用。我一般优先用解压版卸载也简单直接删目录不留注册表残骸。下载渠道上国内网络环境下官网速度不稳定是常态常见做法是从清华 TUNA、阿里云这类镜像站拉 Git for Windows 的压缩包文件名和版本号与官网一致校验 SHA-256 对得上就能放心用。# 假设解压到了 D:\tools\Git D:\tools\Git\bin\git.exe --version # 在 Git Bash 里验证同样可行git bash 本身也在这个目录下 git --version逻辑说明Git 的核心是一堆可执行文件集中在 bin 目录。Windows 命令行默认不认识 git要么写全路径调用要么把 bin 加进 PATH。加 PATH 的常见做法是“此电脑 → 属性 → 高级系统设置 → 环境变量 → Path → 新建”填 D:\tools\Git\bin重开终端就生效。Git Bash 是随 Git 一起提供的模拟器解压版里同样自带日常在 Windows 上敲 Linux 风格命令就靠它。参数说明版本号不用追新但别太老。2.23 之前的老版本对 ed25519 公钥算法的支持不完整Gitee 或公司 GitLab 换成新版密钥时会直接拒绝连接。另一个隐藏较深的坑是换行符选项如果仓库从 Windows 拷到 Linux出现“明明没改但 diff 显示全文件改动”多半是 CRLF 和 LF 没统一。常见做法是 checkout 时保持原样、commit 时用 LF配合 .gitattributes 兜底不要手工翻“自动转换”开关。2.2 全局配置user.name 与 user.email 决定提交记录归属装上 Git 之后第一件事不是急着 clone而是把身份信息写进全局配置。这一步经常被当成无关紧要的小事跳过去结果第一次 commit 时 Git 直接拒绝或者提交记录里出现一个随机生成的“Administrator”名字后面看日志根本不知道谁改的。团队里一旦混入这种无名提交追责和统计工作量都变成一件头疼事。# 设置提交者姓名和邮箱邮箱要填真实常用地址 git config --global user.name 你的名字 git config --global user.email youexample.com # 查看当前生效的全部配置 git config --list # 只需要看某一项值时 git config user.name逻辑说明commit 时 Git 会把 author 信息写进提交对象里这是多人协作时追溯“谁改的”的唯一依据。Gitee、GitLab、GitHub 都用 email 把提交关联到账号头像邮箱设置得与账号不一致提交记录会变成另一个身份哪怕名字一样也不会关联。我有过同事把 email 拼错一个字母整个月提交都显示成两个作者复盘看板时全是碎片最后只能一个个批量改历史。参数说明配置分三层system 是机器级global 是当前系统用户local 是单个仓库。--global 影响本机所有仓库想针对某个仓库例外进仓库目录去掉 --global 再设置一次即可。git config --list 按优先级展开同一项出现多次说明不同层级都有值最终生效的是 local global system。排查配置问题时先看列表里最后出现的值那才是真实生效值。2.3 SSH 密钥配置给 Gitee 设置免密登录这是“git 配置账号密码”这条路线上卡住最多人的环节。每次 push 都弹账号密码框敲完登录密码还要再输一遍用户名一天重复几十次耐心很快耗尽。SSH 免密原理不复杂本地生成一对公私钥公钥上传到 Gitee 或 GitHub之后推送走 SSH 协议远端验证通过就直接放行。# 生成 ed25519 格式密钥-C 只是备注用来区分是哪台机器 ssh-keygen -t ed25519 -C youexample.com # 默认生成到 ~/.ssh/id_ed25519私钥和 id_ed25519.pub公钥 # 查看公钥内容复制整行 cat ~/.ssh/id_ed25519.pub逻辑说明生成过程会问 passphrase我一般直接回车跳过如果所在环境安全要求高可以设置一个之后用 ssh-agent 缓存不用每次输入。公钥可以公开私钥必须留在本机粘贴的时候认准 .pub 结尾的文件千万别把不带 .pub 的私钥内容贴到 Gitee 上。复制后打开 Gitee → 头像菜单 → 设置 → SSH 公钥粘贴保存即可。# 测试认证是否通过 ssh -T gitgitee.com参数说明ed25519 是目前主流的密钥算法比 RSA 2048 更短更快如果目标是特别老的内网 GitLab可能不认识 ed25519回退方案是ssh-keygen -t rsa -b 4096。测试输出Hi xxx! Youve successfully authenticated就算通了。看到Permission denied (publickey)不要急着重新生成密钥先按第 4 章的排查步骤走一遍大部分问题不在密钥本身而在加载和地址上。2.4 图形工具接管 Git 的常见坑IDEA 与 VSCode 的凭据问题命令行跑通切到 IDE 又出幺蛾子是高频剧情。IDEA 的 Git 面板和 VSCode 的源码管理底层调用的都是同一套 Git 命令但凭据处理路径不一样IDEA 用自己的内置凭据存储VSCode 倾向于 Windows 凭据管理器。这就导致一个诡异场景——终端 push 正常IDEA 里却一直报认证失败。原因多半是 IDE 里配置的 Git 可执行路径指向了另一个版本两边的配置和凭据井水不犯河水。常见做法是先确认 IDE 里 Git 路径IDEA 打开 File → Settings → Version Control → Git把 Path to Git executable 换成解压版实际路径VSCode 在 settings.json 里设置 git.path。之后如果还弹旧密码多半是凭据管理器里留着过期记录按 4.4 节的 cmdkey 清掉再试。另一个翻车点是换了电脑克隆仓库时用的还是 HTTPS 地址SSH 配置得再完美也碰不到 SSH 认证记得先看git remote -v输出的协议头。3. 高频命令实战分支合并、commit --amend 与 worktree 的正确边界3.1 分支操作骨架从创建到合并先弄懂底层含义分支是 Git 里用得最多也最容易动作变形的地方。日常开发中我习惯把分支当临时工作台功能没做完的分支不急着合回主干改动都留在分支里随时可以重新整理。创建分支的现代写法是 git switch语义比 checkout 更清晰旧版没有这个命令就用 checkout -b。# 基于当前分支创建并切换到新分支 git switch -c feature/payment # 如果目标分支已存在只想切过去 git switch feature/payment # 查看本地分支与远端追踪关系 git branch -vv逻辑说明switch -c 的 -c 是 createGit 会基于当前 HEAD 位置拉一个新分支并切换。这里有个容易被忽略的点创建分支前先确认自己站在哪个分支上。新分支基于主干还是基于某个特性分支直接影响后面合并的 diff 范围。从一堆未合入的特性分支上再拉分支最后合并时冲突叠加起来会非常痛苦。合并有两种常见结果Fast-forward 和三路合并。Fast-forward 指目标分支没有新提交Git 直接把指针往前挪历史保持一条直线目标分支有新提交时Git 会生成一个 merge commit 把两边改动拼起来。理解这两种结果看到“Merge branch xxx into main”这种自动提交信息就不会慌也能明白为什么有时候合并历史是干净的直线有时候是一团分叉。# 切回主干拉取远端最新代码 git switch main git pull origin main # 把功能分支合并进来如果冲突会停在 merge 中间态 git merge feature/payment参数说明pull 相当于 fetch 加 merge 两步。团队约定用 rebase 的改成git pull --rebase origin main。我个人的习惯是主干用 merge保留合并记录完整自己维护的特性分支在合回主干前如果主干更新了用 rebase 把本地补丁重放到最新代码上历史更线性review 也更容易。但这个偏好必须跟团队约定一致别让仓库里 merge 和 rebase 混着来。3.2 用 commit --amend 改写提交用途、写法与边界git commit --amend 是那种“好用但容易炸”的命令。它的作用是重做上一次提交提交信息打错了想改漏提交了一个文件想补进去都可以用 amend 完成而不会新增一个提交节点。搜索结果里“git commit --amend 怎么使用”热度常年不低说明会背命令的人多真正清楚边界的人少。# 只改最近一次提交的信息 git commit --amend -m fix: correct payment amount calculation # 漏了一个文件先加进暂存区再并入上一次提交 git add . git commit --amend --no-edit逻辑说明amend 的本质是用一个新提交对象替换旧提交旧提交从分支引用上“消失”了这就是为什么改完信息后提交哈希会变。如果旧提交已经 push 到共享分支后果是其他人的本地历史里还留着旧提交你强行推送会被远端拒绝必须 force push。而 force push 到共享分支等于在别人眼皮底下重写历史其他人下次 pull 会撞进很尴尬的冲突。所以边界很简单amend 只用于还没有推送出去的提交。注意amend 只适用于还没有推送出去的提交已经推到共享分支的别 amend否则只能用 force push 收拾残局而 force push 对团队协作的杀伤力很大。git log --oneline -n 3如果 amend 之后又想撤销也不是没有办法。git reflog 会记录所有 HEAD 变化找到 amend 之前的提交哈希再 reset 回去。reflog 是本地操作日志只要没做清理就是 Git 世界的后悔药。我把 reflog 当兜底网用但前提是别养成“先干再说”的习惯尤其在共享分支上。3.3 git worktree一个仓库管理多个工作目录上下文切换是开发里最费神的事。你正在 feature/payment 上写代码写到一半线上出了问题要立刻修。如果只有一份工作目录无非两条路git stash 保存现场然后切走或者强迫自己 commit 一个 WIP 提交。这两条路都会打断思路而且切换成本高。git worktree 给出第三条路一个仓库可以关联多份工作目录每份目录对应不同分支互不干扰。# 为某个分支单独开一份工作目录 git worktree add ../page-maintenance feature/payment-maintenance # 列出仓库关联的所有工作目录 git worktree list # 用完后移除这份工作目录 git worktree remove ../page-maintenance逻辑说明worktree 的底层是在仓库里登记多个 working tree它们的 .git 指向同一个对象数据库。注意一个分支只能被一份工作目录检出你在第二份目录里 checkout 同一个分支Git 会直接拒绝。我一般用它双开新旧版本对比或者接 hotfix 时开一份临时目录完全不碰正在开发的功能分支现场上下文切换成本几乎为零。参数说明add 的路径建议放在仓库目录外的同级位置避免嵌套太深被误清理。remove 的前提是目标目录里没有未提交改动否则会被拒绝如果目录里还有零散改动先处理干净再移除。多出来的目录不要手动删除用git worktree prune清理废记录更稳妥避免仓库登记里残留失效路径。3.4 回滚后悔药reset、revert、clean 三兄弟别混用回滚命令是新手心理压力最大的一块因为用错的代价是删代码、丢提交。先给结论已经 push 到共享分支的用 revert纯本地还没推送的用 reset涉及未跟踪文件的用 clean。这三个命令对应三种完全不同的回滚形态用混了才是真正的灾难。# revert用一次新提交反做旧提交历史完整保留 git revert HEAD # reset移动 HEAD 指针让分支“忘记”某些提交 git reset --hard HEAD~1 # clean清理未跟踪文件-n 先预览会删什么-f 才真正执行 git clean -n git clean -fd逻辑说明revert 不删历史它生成一个反向提交来撤销目标提交适用于已经推到远端的代码因为历史完整同事 pull 不会产生冲突。reset 则是把当前分支引用移回去--hard 同时重置工作区和暂存区本地未推送时想彻底抹掉某段历史很顺手改成 --soft 只移动指针改动回到暂存区--mixed 是默认值把改动退回工作区相当于“回到提交前”。参数说明reset --hard 会彻底抹掉指定提交之后的所有改动执行前先 git status 确认没有未保存的东西。clean 的 -d 参数会把目录也一起删默认只处理文件不确定会不会删错先跑git clean -n -d看预览。团队里有同事把 node_modules 当成未跟踪文件被 clean -fd 删掉的先例虽然不是 Git 的锅但那一整天都在重装依赖。从那以后我每次执行 clean 前都强制自己看一遍预览列表。命令是否改写历史适用场景对已推送提交revert否新增提交共享分支撤销代码安全reset --hard是移动分支引用本地提交整理需 force push不建议clean -fd不涉及历史清未跟踪文件与远端无关4. 排障避坑从 fatal: not a git repository 到 SSH 认证失败的完整排查4.1 fatal: not a git repository目录与仓库脱节现象任何 git 命令都直接拒绝执行终端返回fatal: not a git repository (or any of the parent directories): .git。这不是某个命令坏了是所有 git 命令集体失灵连 git status 这种只读操作也跑不了。原因Git 通过寻找 .git 目录来识别仓库。报这个错只有几种可能当前目录根本不是仓库比如在桌面、下载目录直接敲 git 命令仓库的 .git 目录被删除或移走环境变量 GIT_DIR 被手动指到了别的位置。其中第三种最隐蔽实际排障时遇到过一个案例用户 .bashrc 里设置了 GIT_DIR导致终端一开所有 git 命令都指向一个不存在的路径什么都不做就被挡在门外。解决按顺序排查。# 第一步确认自己在哪个目录 pwd # 第二步看当前目录有没有 .git ls -la | grep .git # 第三步检查 GIT_DIR 是否被手动设置过 echo $GIT_DIR如果在某个子目录执行 git 报错而这个子目录确实在仓库内大概率是符号链接或网络映射盘导致 Git 找不到祖先目录。解决方法是 cd 到仓库根目录再操作或者用git -C /path/to/repo status显式指定仓库位置。注意 git -C 和 cd 后再跑 git 的区别前者不改变终端会话的当前目录适合在脚本里定位仓库。4.2 SSH 认证失败密钥、加载、地址三要素必须对上现象git push 返回Permission denied (publickey)有时还伴随一句fatal: Could not read from remote repository。很多人遇到这个报错就重新生成一遍密钥结果新密钥生成完还是同样报错白白浪费时间。原因SSH 认证失败基本逃不开三个地方。第一本地私钥没被 ssh-agent 加载或者私钥路径不是 SSH 默认搜索的位置第二公钥根本没上传到 Gitee或者上传的不是最新那把公钥第三远程地址本身就是 HTTPS 而不是 SSH 协议这种情况密钥配置得再完美也碰不到 SSH 认证。解决不要一上来就重新生成密钥按顺序查。# 看远程地址到底是 SSH 还是 HTTPS git remote -v # 直接测试 SSH 链路是否通 ssh -T gitgitee.com # 确认 ssh-agent 是否持有私钥 ssh-add -l # 如果没有手动加载私钥 ssh-add ~/.ssh/id_ed25519参数说明如果 ssh -T 输出的是Hi username!说明链路没问题问题在仓库地址把 remote 改成gitgitee.com:user/repo.git这种 SSH 格式。如果输出没有 Hi 而是报错继续看 ssh-add -l 的列表里有没有私钥没有就 ssh-add 加载。还有一层容易被忽略的是 .ssh 目录权限Windows 下不明显Linux 下私钥文件权限如果太宽松SSH 会直接拒用执行chmod 600 ~/.ssh/id_ed25519恢复私钥权限即可。4.3 分支合并冲突冲突标记别怕本质是一个文本问题现象git merge 或 git pull 之后Git 没有直接完成合并而是停在特殊状态打印Automatic merge failed; fix conflicts and then commit the result.。打开冲突文件满屏和看着吓人实际就是文本标记。原因两个分支改动了同一处代码Git 无法判断哪一方才是“正确”的只能把这个决定交给人。冲突不是 Git 坏了是它足够诚实机器不敢替你做的决定就会留给你处理。建立这个认知心态就不会崩。解决打开冲突文件结构是这样的。 HEAD 这是当前分支里这段代码的样子 这是被合并分支里这段代码的样子 feature/payment选择保留哪边还是两边都要直接编辑文件把标记行删掉留下想要的版本。然后执行# 标记为已解决加入暂存区 git add src/payment/service.js # 确认所有冲突都已解决 git status # 提交合并结果 git commit参数说明合并中间态的 HEAD 代表当前所在分支后面跟的是被合并分支名。用 IDEA 或 VSCode 的可视化工具点“接受当前/接受传入”底层就是替你做了编辑并删标记的动作没有任何黑魔法。解决冲突后别急着 commit先跑一遍构建或相关单测因为 Git 的合并结果可能把两个分支的逻辑拼出语义冲突比如变量被删了但另一个文件还在引用这种编译级错误 Git 不会拦你。4.4 git 清除账号密码Windows 凭据残留与明文地址现象换完密码或切换账号后git push 仍然反复报Authentication failed无论重新输入多少次都没用或者输入的是新密码终端却像一直在验证旧凭据。常见于用 HTTPS 方式克隆的仓库。原因Windows 凭据管理器里保存着这条仓库地址的旧用户名和旧密码Git 每次认证优先用本地凭据不弹框不询问导致改完密码还是报错。另一种更极端的情况是 remote URL 里直接写了账号密码比如https://user:passwordgitee.com/user/repo.git这种地址一旦泄露就是实打实的安全隐患。解决先看远程地址再清凭据。# 第一步看 remote -v 输出的地址里有没有账号密码 git remote -v # 第二步清掉 Windows 凭据管理器里的旧凭据 # 先列出匹配项再删除 cmdkey /list | findstr gitee cmdkey /delete:git:https://gitee.com参数说明cmdkey /list 会把凭据管理器里匹配 gitee 的条目列出来/delete 的完整参数要跟列出的目标名一致否则删不到。删除后下次 push 会重新弹框输入新密码就正常了。如果 remote 地址里能看到用户名或密码用下面的命令替换成干净地址git remote set-url origin https://gitee.com/yourname/yourrepo.git我一般还多走一步确认远程仓库支持 SSH 后直接把 HTTPS 地址换成 SSH 地址这样既免密也不再有密码残留和过期问题。这条经验在处理公司内网 GitLab 时同样适用内网换密码的频率往往更高。5. 一套可验证的交付习惯状态检查、暂存改动与回滚预案5.1 开工前先做三次检查status、log、diff代码提交前我固定做三个动作坚持下来之后“提交错文件”“漏提交”“把调试代码推上去”这些事故基本被挡在门外。# 看工作区状态确认哪些文件被改过 git status # 看最近提交历史确认当前 HEAD 在哪 git log --oneline --graph --all -n 10 # 检查差异里有没有空白错误 git diff --checkgit status 解决“我改了什么”git log 解决“我站在哪”git diff --check 查的是提交里混入行尾空格、空行这类不痛不痒但 code review 时会被挑出来的问题。执行顺序我习惯 status 在前因为工作区有遗漏时后面看历史意义不大容易把改动提交到错误的分支上。5.2 中途被打断用 stash 保存半成品工作做到一半必须切换分支又不想为了切分支强行提交半成品 WIPstash 就是专门干这个的# 把当前改动暂存起来工作区恢复干净 git stash push -m wip: payment integration not finished # 查看暂存列表 git stash list # 切到其他分支办完事切回来之后恢复改动 git stash apply # 确认恢复无误后删除这条暂存记录 git stash drop参数说明apply 会把改动恢复到当前工作区但不会自动删除 stash 记录恢复后确认代码没问题再 drop 掉避免列表越来越乱。如果有冲突apply 的表现和 merge 一样按冲突解决流程走就行。另一种更彻底的做法是结合 worktree直接开新目录处理其他分支当前现场完全不打断适合需要同时开工两个任务的场景。5.3 让命令验证成为习惯这套东西光看没用找个临时目录把完整流程跑一遍比读十遍教程都有用mkdir demo cd demo git init echo line1 app.txt git add app.txt git commit -m init git switch -c feature echo line2 app.txt git add . git commit -m feature change git switch main echo line2-main app.txt git add . git commit -m main change git merge feature这里一定会撞出冲突正好把前面避坑章节讲的冲突标记、解决流程、reset 和 revert 全部练一遍。看到冲突别慌编辑、add、commit操作乱了就 reflog 找回。真正的熟练是把这些命令变成肌肉记忆而不是收藏夹里的教程。从那以后我每次 merge 或者 force push 之前都会强制自己先跑一遍 status 和 log把当前所在分支与未提交改动确认清楚再动手。这个习惯帮我挡下了至少三次误操作。希望帮到你。本文还有配套的精品资源点击获取