简介：PortableGit V2.35（64位）是一款面向Windows开发者的Git便携发行版，适合需要随时随地进行代码版本管理而无需在主机上安装软件的用户。该版本基于Git 2.35，内置命令行工具、Git GUI图形界面与Git Bash终端，覆盖克隆、暂存、提交、推送、拉取及分支合并回滚等完整工作流，既能满足命令行习惯的开发者，也为不熟悉指令的用户提供可视化操作入口。压缩包共6057个文件，约115MB，包含vim脚本、Perl模块（pm/pl）、exe程序、动态链接库（dll）以及html/txt帮助文档等，系统构成了Git核心程序及关联工具链的完整运行环境。已有306人学习。相比安装版，PortableGit免安装、免写入系统目录，解压即可用，可放入U盘或移动硬盘，在任意Windows电脑上获得一致的版本控制体验，不留系统残留。对经常切换设备、使用受限环境或需要快速搭建Git工作环境的开发者来说，是实用且高效的选择。
1. 把 Git 装进 U 盘：PortableGit V2.35 到底是给谁用的
早年我在某公司驻场，会议室那台办公电脑没有开发环境，每次改完代码都得等别人把 Git 装好才能提交。后来换成 PortableGit V2.35（64 位）这个绿色便携版，U 盘一插，几分钟就接管了这台机器的版本控制环境。所谓 PortableGit，就是官方把 Git 本体、MSYS2 运行时、Bash 工具链全部打进一个 7z 压缩包，解压即用，不写注册表，不带安装向导。它解决的第一个痛点是环境隔离：想用哪个版本的 Git，就解压哪个目录；第二个痛点是携带性：整个工具链可以放在 U 盘、移动硬盘甚至网络盘里。你只要在命令窗口临时指一下 PATH，这台机器就变成了你的 Git 工作台。适合经常换电脑交付、有环境洁癖、或者想同时维护多套 Git 版本的人。
2. 先看懂 PortableGit 的目录结构：为什么它敢自称“绿色免安装”
2.1 解压后这堆目录分别是谁
拿到 PortableGit V2.35 的 7z 包之后，先别急着扔进 PATH，花两分钟看清它的目录布局，后面排错能省很多时间。解开后能看到 cmd、bin、usr、etc、mingw64 这些顶层目录，再加上根目录下的 git-bash.exe、git-cmd.exe 两个入口。很多人以为 Git 装完就只是一个 git.exe，实际上它背后是一整套 POSIX 兼容层。
| 目录 | 职责 | 我的使用习惯 |
|---|---|---|
| cmd | Windows 原生命令入口，git.exe 在这里 | 加 PATH 时优先加这个目录 |
| bin | 内部可执行文件、脚本依赖 | 一般不动，偶尔手动调用 |
| usr | 从 MSYS2 继承的 Unix 工具集，grep、sed、ssh 都在这 | 写脚本时会用到 /usr/bin 下的命令 |
| etc | 全局配置模板，gitconfig 初始值在这 | 多环境部署前会先改这里 |
| mingw64 | 64 位编译的 Git 本体和运行时 | 真正干活的地方 |
这份结构说明了一个关键事实：PortableGit 不是把一个安装版目录打包了事，而是通过 MSYS2 的运行时把 Unix 工具和 Windows 原生程序拼在一起。所以它体积比安装版大一截，但这换来的是接近 Linux 环境的脚本兼容性，例如 usr/bin 里的 bash、grep、awk 全是可用的，git-bash.exe 打开后就是一套现成的 Unix shell。
2.2 为什么 V2.35 这个版本值得留一份
版本选择上没有绝对最新，只有够用和稳定。V2.35 发布到现在已经经过足够长的时间验证，社区反馈里常见的 submodule、lfs、rerere 相关缺陷基本被后续补丁覆盖，又没有像某些大版本那样引入激进的默认行为变化。实际项目里，我见过团队因为同步到新版 Git 后 fsmonitor 行为变化导致 IDE 卡顿，最后全组回退到 2.35.x 线的情况。
另一个值得留一份的理由是便携版可以并存多版本。我笔记本上同时放着 2.35 和更新的版本，两个目录不冲突，通过 .bat 切换 PATH 顺序就能决定当前终端用哪套 Git。对于需要复现某环境下的特殊行为、或者仓库里残留了老格式元数据的场景，留一个 V2.35 绝对是后悔药。
2.3 怎么验证它真的“不写注册表、不占全局”
绿色便携最大的风险不是功能不全，而是你以为它没落地，实际它碰了系统。一个很常见的现象：安装版 Git 会往用户目录写全局 .gitconfig，还会注册右键菜单。而 PortableGit 的配置位置完全不同，验证方法就是用--show-origin看配置来源。
git config -l --show-origin这段命令会列出当前生效的全部配置项，并标注每一项来自哪个文件。正常情况你会发现 source 指向<U盘盘符>\PortableGit\etc\gitconfig或\PortableGit\home\用户名\.gitconfig，而不是C:\Users\xxx\.gitconfig。如果出现系统用户目录里的配置，说明全局 HOME 没有锁定到便携目录，后面第 4 章会专门处理。
再看注册表痕迹，用管理员权限打开命令提示符，执行：
where git reg query "HKCU\Software\Git" 2>nulwhere git会显示当前终端实际能找到的 git.exe 路径，如果不是便携目录里的，说明系统里还装了另一套 Git 在抢占 PATH。注册表查询那条如果返回“系统找不到指定的注册表项或值”，说明 portable 没往当前用户注册表写安装信息，这两个命令配合，基本就能确认这套 Git 是不是真“绿”。
3. 如何接管一台 Windows 机器：从解压到全局替换系统 Git
3.1 目录规划与解压
把 7z 包解压前先想清楚这个 U 盘会被插到哪些机器上。我的习惯是固定一个盘符根目录，比如D:\Tools\PortableGit，不直接把压缩包内容散到桌面或下载目录，否则 HOME、SSH 密钥、仓库路径全都会跟着乱。
解压这一步没有技术含量，真正要注意的是解压工具。Windows 自带资源管理器只支持 zip，7z 包要先装解压软件，或者在有 7-Zip 命令行的机器上用下面这条把 PortableGit 释放到目标路径：
7z x PortableGit-2.35.0-64-bit.7z -oD:\Tools\PortableGit参数说明：x表示按完整目录结构解压，-o后跟目标目录，注意-o后面不要有空格。解压完成后进入D:\Tools\PortableGit，看到git-bash.exe就说明包完整。我建议解压后先双击git-bash.exe跑一次git --version，确认 64 位版本在这个 Windows 下能正常拉起，再去动环境变量，避免排查时搞不清是解压失败还是 PATH 写错。
3.2 PATH 环境的临时注入与永久写入
“便携”不等于完全不动系统。想让这台机器上的命令行工具认出git，要么每开一个终端手动指一次路径，要么把路径写进用户环境变量。临时方式适合交付现场一次性使用：
set PATH=D:\Tools\PortableGit\cmd;D:\Tools\PortableGit\bin;D:\Tools\PortableGit\usr\bin;%PATH% git --version这段命令的意思是：把 PortableGit 的三个关键子目录插到现有 PATH 的最前面，让系统优先执行便携版的 git，而不是残留的其他版本。set只在当前命令窗口生效，窗口关闭即失效，适合不想留下痕迹的场景。
要想长期接管这台机器，用setx把 PortableGit 写进用户环境变量：
setx PATH "D:\Tools\PortableGit\cmd;D:\Tools\PortableGit\bin;%PATH%"这里有个坑：setx会把当前窗口的%PATH%展开后再写入，如果当前窗口已经被污染、或者原 PATH 里有变量引用如%JAVA_HOME%，展开后这些引用会被转成绝对路径，长期使用可能造成系统工具异常。所以我一般先用echo %PATH%确认干净，再执行 setx，并且写完用新开的命令窗口验证而不是在当前窗口验证。
3.3 立即初始化用户身份与换行符策略
PATH 生效后第一件事不是 clone 仓库，而是把身份信息写进便携版自己的全局配置。很多人在这步随手敲了和系统用户相同的名字，换机器后想改全局配置又要到处找。
git config --global user.name "某开发者" git config --global user.email "dev@example.com" git config --global core.autocrlf input第一行设置提交人显示名，第二行设置邮箱，这两项缺失时提交会被 Git 强制拦截。第三行core.autocrlf input是我在 Windows 上的固定策略：提交到仓库时把 CRLF 转成 LF，检出时不做反向转换。这样仓库内保持纯 LF，和同事的 Linux 环境不会互相污染，代价是 Windows 上本地文本文件会显示 LF，对大多数项目没有影响。如果你经常在 Windows 上写 PowerShell 脚本，也可以设true，检出时自动变 CRLF，取舍点后面第 5 章再细说。
3.4 SSH 密钥与 HTTPS 凭据迁移
交互式登录方案需要趁早配好。便携版的 HOME 如果默认指向系统用户目录，用的还是原来那套密钥，一旦 HOME 改成便携目录，就必须在新 HOME 下生成密钥。
ssh-keygen -t ed25519 -C "dev@example.com" -f ~/.ssh/id_ed25519-t指定算法，ed25519比 RSA 更短更快，兼容性在 2022 年后的 Git 托管平台上没有问题；-C是注释标记，通常填识别用的邮箱；-f指定生成路径，~/.ssh/会跟随 HOME 指向便携目录。生成的私钥留在本地，公钥id_ed25519.pub内容复制到托管平台。HTTPS 场景我建议避开凭据管理器，直接配置让 Git 使用自带的凭证存储：
git config --global credential.helper manager-coremanager-core是跨平台凭据管理器，弹窗保存密码后会写入 Windows 凭据保管库，不会落进便携目录。如果你要的是完全无痕，配credential.helper cache加上--timeout=3600，内存里留一个小时，重启即空。
4. 多环境切换：U 盘上的 Git 如何在办公机和家机之间无缝同步
4.1 把 HOME 锁进便携目录，一切配置跟着 U 盘走
很多人误以为 PortableGit 解压到 U 盘就天然“全随身”，实际默认行为下，它还是会读取系统用户目录里的 .gitconfig 和 .ssh。要做到真正同步，必须把 HOME 环境变量指向 U 盘上的某个固定目录。我这里统一建了E:\PortableGit\home，里面放.gitconfig、.ssh、.bashrc。
set HOME=E:\PortableGit\home setx HOME "E:\PortableGit\home"第一条让当前窗口立刻生效，第二条让以后所有新进程读到同样值。注意：setx不会影响已经打开的窗口，因此每次插入 U 盘后，我已经开着的终端需要重开一遍才能识别新 HOME。这块特别容易翻车：第一次配完 HOME，普通命令窗口和 PowerShell 读到的值不同，因为 PowerShell 会继承开启瞬间的环境变量，而不是每次执行命令都重读。所以切换环境后，强制全部终端新开，不要依赖旧窗口。
4.2 三份 config 的生效边界：system、global、local
配置按作用域从宽到窄分成 system、global、local 三层。system 对应PortableGit\etc\gitconfig，管的是这套 Git 本身的默认值，比如 Windows 上常见的core.symlinks = false；global 对应 HOME 下的.gitconfig，管理当前用户所有仓库；local 则藏在每个仓库的.git/config里，只对这个仓库有效。
git config --system --list --show-origin git config --global --list --show-origin git config --local --list --show-origin参数说明：--list列出该作用域全部配置，--show-origin追加显示配置文件的绝对路径。我在多机器间排查问题时，先跑这三条命令，马上能看出某条配置是写在便携版里、U 盘 HOME 里还是某个仓库内部。一旦办公机和家机的配置不一致，优先查 global，因为 system 在 U 盘里是共用的，local 在仓库里也是随仓库走的，最容易漂移的就是 HOME 没锁死时各自落在不同机器用户目录里的 global 配置。
4.3 批量迁移旧仓库的本地配置
把原来用安装版 Git 管理的仓库迁移到便携版时，最笨的方法是进每个仓库手动重配 user.email，我实际搬过四十多个仓库，后来写了一个遍历脚本。Git Bash 里跑下面这段：
for dir in /e/workspace/*/; do if [ -d "$dir/.git" ]; then git -C "$dir" config --local user.email "dev@example.com" git -C "$dir" config --local branch.autosetuprebase always echo "done: $dir" fi donefor dir in /e/workspace/*/枚举工作目录下的所有子目录，-d "$dir/.git"判断这是不是仓库，git -C "$dir"表示在指定目录执行命令，避免每轮cd造成脏状态。branch.autosetuprebase always是让新建的本地分支跟踪远端时默认采用 rebase，这是纯个人偏好，不需要照抄。脚本跑完后挑几个仓库执行git config --local --list抽查，确认没有仓库漏掉。
4.4 仓库路径漂移问题：U 盘盘符变了怎么办
U 盘的盘符不固定是最影响便携体验的一件事。今天插上电脑显示 E:，换一台机器变 F:，仓库里的 absolute 路径全部哑火。我自己在home目录下放了一个init.sh，每次换机器先跑一次：
#!/usr/bin/env bash export HOME="/f/PortableGit/home" export PATH="/f/PortableGit/cmd:/f/PortableGit/bin:/f/PortableGit/usr/bin:$PATH" cd /f/PortableGit脚本第一行固定 HOME，第二行固定 PATH，第三行把当前目录切到便携根目录。执行前先看一眼实际情况，盘符可能是 E 或 F，把脚本开头的盘符改掉再 source 即可。这种半自动方式比硬写死盘符靠谱，至少把需要改动的地方收敛到一个文件里，不至于每次换机器都从头现配。
5. 避坑：随身携带 PortableGit 时最容易翻车的五个瞬间
5.1 拔掉 U 盘后 Git 命令全丢，PATH 残留还在指向旧盘符
现象：同一台办公电脑，插入 U 盘时git --version正常，拔掉 U 盘后所有终端里 git 命令报“不是内部或外部命令”。原因：setx 写入的 PATH 包含了E:\PortableGit\cmd，盘符消失后路径失效，系统找不到任何 git。解决：临时用绝对路径执行，或把 PATH 里失效的目录清掉。
set PATH=%PATH:;E:\PortableGit\cmd=% set PATH=%PATH:;E:\PortableGit\bin=%这是批处理变量替换写法，%PATH:;E:\...=%意思是把 PATH 字符串里匹配;E:\PortableGit\cmd的部分替换成空。执行后echo %PATH%确认干净，再where git看是否还有其他 Git 可用。
5.2 中文文件名和 commit message 乱码
现象：git status显示“\346\235\220\346\226\231”这串转义序列，或者提交信息里的中文变成问号。原因：Git 默认对非 ASCII 路径做转义显示，同时 Windows 下命令行代码页不是 UTF-8，输出时编码错乱。解决：关闭路径转义并固定输出编码。
git config --global core.quotepath false git config --global i18n.logoutputencoding utf-8 git config --global gui.encoding utf-8core.quotepath false关闭八进制转义，让中文原样显示；i18n.logoutputencoding控制日志输出的编码；gui.encoding只影响图形界面工具。改完这条，旧仓库里的中文文件名立刻正常，前提是文件本身的编码还是 UTF-8，如果是 GBK 命名的老仓库，这条救不了。
5.3 CRLF 与 LF 混战，提交记录里全是“删除再添加”
现象：同一份文件在不同机器上切换后，git diff显示整个文件被删除又添加，实际内容没变。原因：一台机器 core.autocrlf=true，另一台是 false，Git 认为是两个不同文件。解决：先确认仓库里现在存的到底是什么换行符，再统一策略。
git config --global core.autocrlf input git config --global core.eol lfcore.eol lf强制 Git 用 LF 作为工作区内容的换行符，配合input后入库和出库都固定为 LF。已经在仓库里混入 CRLF 的历史，可以后续用.gitattributes配合过滤器重写历史，但那需要全组协调，不能只在一台机器上改。
5.4 杀毒软件把 PortableGit 当作可疑程序拦截
现象：解压完第一次运行git-bash.exe，Windows 提示风险或杀毒软件直接隔离了 usr/bin 下的某个 dll。原因：便携版不经过注册表和安装流程，签名文件又集中在少数几个 exe 上，某些引擎会对大规模释放的可执行文件群产生误报。解决：把整个便携目录加进白名单，或者重新解压并校验包哈希。加白名单路径要精确，只加一级目录不够，杀毒软件扫描到 mingw64 里的深层 dll 仍然会拦截。我实际遇到一次隔离后所有命令都提示“拒绝访问”，重装系统后把那台机器的实时防护目录精确到E:\PortableGit整个目录才消停。
5.5 HOME 指向系统用户目录导致多台机器配置互相污染
现象：办公机和家机用的同一个 U 盘，提交人邮箱一会是公司的，一会是个人邮箱。原因：HOME 没有全局注入，或者注入后未生效，Git 回退到读取C:\Users\用户名下的 .gitconfig。解决：确认当前 HOME 到底在哪。
git config --global --show-origin --list这条命令里--show-origin能看到 global 配置文件的实际路径。如果写的是C:\Users\xxx\.gitconfig，说明 HOME 没生效。检查系统环境变量里 HOME 是否被设置、当前终端是否重开过，然后重新执行第 4 章的setx HOME并重开终端。这个坑排查成本不高，但极其阴险，因为有时候只有提交那一刻才会发现身份错了，代码已经推上去了。
6. 进阶玩法：把 V2.35 当作可编程环境来用
到这里，PortableGit 已经从“临时替代品”变成了“随身工具链”。再往前走一步，我会在PortableGit\home下写一个pg.sh，把所有常用的跨机器操作封装成别名。比如我在 Windows 命令提示符里敲pg直接调用 U 盘上的 git，而不是依赖 PATH 顺序：
alias pg="E:/PortableGit/bin/git.exe" pg --version这个别名只在当前 Git Bash 会话里有效，需要长期存在就把它写进home/.bashrc。另一个值得做的操作是把全局配置定期导出备份，防止 U 盘损坏后配置一起消失：
mkdir -p /e/PortableGit/backup git config --global --list --show-origin > /e/PortableGit/backup/global-config.txt cp /e/PortableGit/home/.ssh/id_ed25519.pub /e/PortableGit/backup/这两条命令把全局配置面板和公钥备份到便携目录内部，下次换新 U 盘时不需要重新回忆自己设过哪些别名和忽略规则。多版本并存时，我会在根目录放一个switch.bat来切换默认调用的 Git：
@echo off set GIT_HOME=E:\PortableGit set PATH=%GIT_HOME%\cmd;%GIT_HOME%\bin;%PATH% echo Switched to PortableGit V2.35这段批处理的关键在于它每次都在当前窗口最前面插入 PortableGit 路径，即使系统装了新版 Git，where git也会先找到这里。从那以后，我每到一个新环境都强制走一遍固定流程：解压、查看目录结构、锁定 HOME、注入 PATH、验证配置来源。这套流程前前后后帮我省掉了至少十次环境现场救火。希望帮到你。
本文还有配套的精品资源，点击获取
