简介：PortableGit V2.35（64位）是为Windows平台打造的Git便携发行版，面向需要在多台电脑间移动开发、又不愿安装复杂环境的开发者，解决版本控制工具随身携带与快速使用的问题；V2.35更新包含性能提升、新功能与错误修复，较旧版更稳定。软件集成Git命令行工具、Git Bash终端、Git GUI图形界面及必要运行库，可在U盘或移动硬盘中直接运行，不在主机系统留下痕迹，也便于离线或受限网络环境下使用。压缩包约115.03MB，内含6057个文件，核心为exe、dll等可执行程序与运行库，辅以pl/pm/sh/py等脚本来扩展命令，html、txt等构成文档帮助体系，vim/tcl等为编辑器与环境配置。已有306人学习下载。借助内置的分支管理、合并、回滚及常用git clone/add/commit/push/pull操作，用户可以高效完成代码版本管理和团队协作；Git Bash还可提供类Unix体验，Git GUI则降低命令行门槛，适合从入门到进阶的开发者随时调用。

1. PortableGit V2.35（64 位）Windows 便携版：从 U 盘里跑起来的一整套 Git 环境

如果只是临时跑个项目，没人愿意在一台陌生的 Windows 上一步步点安装向导。PortableGit V2.35（64 位）就是那个解压即用的选择：它不写注册表、不往系统目录里塞文件，解压到一个文件夹就能开出完整的 Git Bash，版本由你说了算，换机器拔 U 盘就走。我自己的 U 盘里常驻一份这样的便携版，遇到客户机器、CI 环境或者刚装好的系统，第一件事就是把它拉出来用。它的价值对你来说分三种：想在一台机器上维护多个 Git 版本，项目要求固定版本不跟着系统升级走，或者单纯不想让安装过程污染环境。下面就从解压到配置、踩坑，把它讲透。

2. 部署与验证：解压后怎么让 cmd 和 PowerShell 都认出 git

2.1 解压与启动方式：不只是双击 git-bash 这一条路

拿到 V2.35 的压缩包之后，先找一个没有特殊权限要求的目录。官方倾向于解压到某个盘的根目录，但实际使用中放在 D 盘深层路径也可以。我一般会解压到 D:\portable-git\，路径里不要有空格和中文字符，后面做脚本调用时会少很多烦恼。解压完成后顶层目录大致长这样：

• cmd\git.exe：仅供 Windows 命令行直接调用的入口，后面 PATH 配的就是这个目录。
• git-bash.exe：完整模拟 unix 环境的终端，日常交互式操作首选。
• usr\bin\bash.exe：被脚本间接调用的 bash 本体，做自动化时用这条路径。
• etc\：Git for Windows 的全局配置文件目录，里面有 gitconfig 和 inputrc。

启动方式可以分三层理解。交互式用 git-bash.exe，它会自动加载 /etc/profile，把 unix 工具链都塞进 PATH；Windows 原生终端里用 cmd\git.exe，前提是 PATH 要配好；脚本里用 usr\bin\bash.exe --login 来跑 .sh 文件，这层最可控，同一份脚本在不同机器上的行为是一致的。很多人只停留在双击 git-bash，一旦代码里需要调用 git 命令就翻车，问题往往不在 PortableGit 本身，而是启动方式没选对。

还有一个细节值得注意：git-bash.exe 和 usr\bin\bash.exe 是两个不同层级的入口。前者是图形终端包装，会新开窗口；后者是纯命令行 bash，适合被其他进程调用。日常提交代码用前者，写自动化任务用后者，不要把两者混着用。我在一台没装过 Git 的干净机器上验证过，解压完成后直接用 git-bash 就能跑 git clone，这也是便携版最直观的价值：解压即用。

2.2 把 cmd 目录放进 PATH：setx 的坑与更稳的替代

如果只开 Git Bash，PATH 配不配无所谓，因为 git-bash 启动时自己会加。但要在 cmd、PowerShell 和各类编辑器里直接敲 git，就得把 D:\portable-git\cmd 加进 PATH。常见做法是用系统设置里的「环境变量」对话框，在用户变量 Path 里追加这一条。我不推荐用 setx：

setx PATH "%PATH%;D:\portable-git\cmd"

这条命令有两个坑。第一，setx 对环境变量的长度上限是 1024 个字符，一旦原 PATH 太长，多余部分会被静默截断，等你下次重开终端才发现一堆工具找不到了。第二，%PATH% 展开的是运行时合并了系统变量和用户变量的完整值，setx 会把这份合并结果写回用户变量，等于把系统目录也抄了一份进去，之后系统目录更新你的用户变量也不会跟着变，逻辑上就拧巴了。

更稳的做法有两条。图形界面里用 sysdm.cpl 手动改，这个大家都会；自动化场景里我一般用 PowerShell 改用户级 Path：

[Environment]::SetEnvironmentVariable( "Path", [Environment]::GetEnvironmentVariable("Path", "User") + ";D:\portable-git\cmd", "User" )

这段代码只操作 User 作用域，不会把系统 PATH 混进来，也不会触碰到 1024 字符的截断。参数上唯一的注意点是：用户级 Path 可能包含 %USERPROFILE% 这类未展开变量，读出来写回去时最好用原始字符串，别让它展开成绝对路径。改完以后，当前已经打开的终端不会自动感知，重开一个窗口再验证。

PowerShell 里还有一个临时验证的小技巧：不用改永久变量，直接在当前会话刷新 $env:Path，适合你只想在当前窗口试一下的场景。但注意这只是会话级生效，下次开终端就没了，不能替代真正的用户级配置。

2.3 版本验证与多 Git 排查：怎么确认跑的是 PortableGit 而不是别的

PATH 配完，重开一个终端，先验证三件事：

git --version git --exec-path which git

第一条确认版本，V2.35 会输出 git version 2.35.1.windows.2 这种带 windows 标记的版本号；第二条确认内置命令在 PortableGit 目录下，而不是某个系统自带 Git 的安装位置；第三条在 cmd 里应该显示 D:\portable-git\cmd\git.exe。如果 which git 指向的是 C:\Program Files\Git\cmd\git.exe，说明系统里已经装了别的 Git，并且它的 PATH 顺序排在你前面。

这里不妨多说两句 Windows 解析命令的机制。Windows 按 PATH 从左到右找第一个命中的可执行文件，找到就用，不再往后看。所以 PortableGit 想生效，要么把它的 cmd 目录往前挪，要么在需要时用绝对路径调用。Git Bash 内部对 Windows PATH 的加载顺序有自己的规则，它会在启动脚本里把自己 unix 工具目录优先，所以双击 git-bash 时 git 命令多半没问题，问题集中在 cmd 和 PowerShell。

排查时用 where git 列全部候选路径，一眼就能看到底是哪一份 Git 在响应。这种问题往往不是 PortableGit 的问题，是系统里本身就有安装版 Git，两个并存时产生了优先级竞争。把 PortableGit 的用户 PATH 条目前移之后，再执行 git --version 确认变更生效。版本验证这一步里，git --exec-path 我建议每次都看一眼，因为它能暴露内置命令的物理位置，比单纯看版本号更能确认到底在执行哪一套。

3. 初始化一组能随身带的配置：用户信息、换行符与凭证

3.1 全局用户信息与配置文件位置的取舍

解压后第一件事是配置 user.name 和 user.email。这个大家都知道，但 PortableGit 场景下有个特殊点：全局配置写到哪个 HOME 下。默认情况下，PortableGit 的 HOME 指向 C:\Users\你的用户名，也就是和系统安装版 Git 共用同一个 .gitconfig。如果你只是想临时用，这没问题；但如果你想让便携环境真正独立，就得把 HOME 指到 PortableGit 目录附近。

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这两条命令决定的只是往哪个文件写配置。--global 对应用户级 $HOME/.gitconfig，--system 对应 PortableGit 的 etc/gitconfig，--local 对应仓库内 .git/config。优先级是 local > global > system。我的习惯是：别名、换行符这类通用偏好放 global，机器相关的配置也尽量放 global，不碰 system 文件。因为 etc/gitconfig 在 PortableGit 升级时可能被覆盖，放自己可控的 global 更省心。

想让配置跟着 U 盘走，只需在启动 git-bash 之前把 HOME 环境变量指向便携目录下的一个子目录，例如 D:\portable-git\home。之后所有 --global 配置、SSH 密钥、还有 .gitconfig 都会落在那个目录里，换机器解压一份新的 PortableGit，把环境变量一配，配置就全回来了。这里的关键是理解 HOME 的作用范围：git 配置、ssh 找密钥、bash 找 .bashrc，全都会看这个变量。不要把它和 Windows 的 USERPROFILE 混为一谈，那两个指向不同的语义。

3.2 换行符策略：autocrlf 三个选项和 .gitattributes 兜底

Windows 上 Git 最经典的问题就是换行符。仓库里存 LF，Windows 编辑器默认 CRLF，如果不管，会出现每次进入编辑都提示文件被修改的情况。core.autocrlf 有三个值：

• true：Windows 下推荐。checkout 时把 LF 转 CRLF，commit 时把 CRLF 转 LF。单机用很省心。
• input：提交时把 CRLF 转 LF，checkout 不转换。适合你确定编辑器会输出 LF、只是想把脏行尾挡在提交之前的情况。
• false：完全不转换。项目里已经有严格 LF 规范、或者仓库文件类型复杂时用这个。

V2.35 的 Git for Windows 默认值是 true。但我不建议在配置文件里单独依赖这一个开关，因为不同同事的 autocrlf 各不相同，仓库里既有 LF 又有 CRLF 时照样会乱。更稳的做法是仓库根目录维护 .gitattributes，用规则声明哪些文件用什么行尾：

* text=auto *.sh text eol=lf *.bat text eol=crlf *.png binary

text=auto 让 Git 对文本文件做规范化，eol=lf 和 eol=crlf 精确锁定各类型文件的行尾，binary 把二进制文件排除在外。.gitattributes 在团队仓库里是提交到远程的，所以它的规则对所有人生效，优先级高于各人本地的 autocrlf。我个人经验是：只要是跨平台项目，.gitattributes 必须进仓库，本地 autocrlf 只是兜底。换行符问题处理完后，如果仓库里已经有旧文件带着错误行尾，跑一遍 git add --renormalize . 让 Git 按新规则重新规范化索引，这是不重写工作区的最快办法。

如果行尾告警只是偶尔出现，不想大动干戈，也可以在本地把这个仓库的 autocrlf 显式关掉。但这样做的代价是工作区会混入仓库原本的 CRLF，下次提交时又把脏行尾提交进去，治标不治本。我的建议始终是：全局配置用默认 true，仓库规则交给 .gitattributes，两边各管一段。

3.3 SSH 密钥与凭证助手：换机器后最常翻车的这步

连接远程仓库时，推荐用 SSH 而非 HTTPS，因为密钥比密码好管理。在 Git Bash 里生成密钥：

ssh-keygen -t ed25519 -C "你的邮箱" -f ~/.ssh/id_ed25519

-t ed25519 比默认的 rsa 更小更快，V2.35 的底层 OpenSSH 支持没问题。如果你要连的是老旧服务器，才需要退回 rsa 4096。生成后把 ~/.ssh/id_ed25519.pub 的内容粘贴到代码托管平台的 SSH keys 设置里。注意：在多台电脑场景下，不建议把同一份私钥往机器间复制。正确做法是每台机器各自生成密钥对，把各自的公钥都配到账号下，哪天某台机器丢了，吊销那一把公钥就行，其他机器不受影响。

如果你偏好更省事的方式，也可以把私钥放进随身目录、配一个 ssh-agent 统一管理。具体来说，在 .bashrc 里加一句 eval $(ssh-agent) 再 ssh-add，Git Bash 每次启动自动加载密钥，输一次口令，之后一个会话内都不用再输。这个方案适合密钥有口令保护的人，丢 U 盘也不至于直接泄露。

凭证方面，V2.35 的默认凭证助手是 manager-core，它在完整版 Windows 上表现正常，但一些精简过的系统缺少运行库，git pull 时会一直弹窗或直接报找不到 git-credential-manager-core。遇到这种情况，最省事的后备方案是切到 store 模式：

git config --global credential.helper store

store 模式把凭证明文写在 ~/.git-credentials，好处是命令不弹窗、一次性配好，坏处是明文风险。我的处理方法是：只在可信的内网仓库或者临时环境用 store，离开前记得删掉这个文件。还有一点容易被忽略：切换凭证助手后，已经缓存过的老凭证不会立刻失效，如果 push 后发现还在用旧账号，就去 Windows 的「凭证管理器」里把对应条目删掉再重试。凭证助手选型上，我一般先试默认的 manager-core，它弹窗次数最少；报错再降级到 store，而不是一开始就用 store。

4. 常见问题与避坑：部署和日常使用中的五个翻车点

4.1 部署阶段：闪退与 PATH 抢占

现象一：双击 git-bash.exe 闪退，命令行窗口一闪就没了。原因大概率是安全软件把 PortableGit 的关键 dll 或者 usr/bin 下的可执行文件隔离了。解压动作触发实时扫描，文件刚落地就被带走，bash 起不来。解决：先把压缩包放到本地磁盘再解压，解压时临时退出安全软件，解压完成后把目录加白名单。还有个小概率原因是解压到网络路径或权限受限的系统目录，把 PortableGit 放到用户有完整读写权限的位置。

现象二：在 cmd 里敲 git --version，显示的版本不是 V2.35，而是系统里另一个老 Git。原因不是 PortableGit 没装好，是 PATH 检索顺序里系统的 Git 目录排在前面。解决：用 where git 列出所有候选，然后把 PortableGit 的 cmd 目录在用户 PATH 里往前调。如果始终有小工具优先调用系统目录，最直接的办法就是在调用时写完整路径，后面脚本化调用时我会这么做。

4.2 日常使用阶段：换行符告警与终端找不到 git

现象三：每次 git add 都提示 LF will be replaced by CRLF 或者反过来，看着烦，偶尔还担心是否改了文件。原因就是 core.autocrlf 和仓库已有文件的行尾不匹配。这通常不是错误，只是提示，但大量告警会掩盖真正的报错。解决：先把仓库根目录的 .gitattributes 立起来，让规则入库；本地再确认 autocrlf 不是 false。规则改完后，跑一次 git add --renormalize . 让 Git 按新规则重新规范化索引里的行尾，然后提交一次，告警基本消失。

如果迟迟不动 .gitattributes，只是每次告警时手动忽略，仓库里就会慢慢混入两种行尾的文件，最终某天 git diff 出现整文件级别的改动，那时候已经分不清是真实改动还是行尾漂移。换行符的问题不能拖，越拖越难收拾。

现象四：明明 PATH 已经加进系统设置，PowerShell 里 git 还是「无法识别」。原因：当前终端会话启动时 PATH 已经加载，系统设置的修改不会自动进入已经打开的会话。解决有两种：重开终端让新 PATH 生效，或者只对当前会话临时刷新。别在一开着的窗口里反复测验，这会让人误以为配置坏了。在 PowerShell 里临时生效的命令是 $env:Path = "D:\portable-git\cmd;" + $env:Path，加了之后就立即能用，只是重启终端会失效。

这个坑最常见的翻车场景是：改了环境变量后，编辑器或 IDE 里集成的终端不重启，直接调 git 报错，于是以为配置没写进去。实际上环境变量写成功了，只是当前进程没拿到新值。工具链里的每一个进程都应该重启，不光是终端窗口本身。

4.3 配置迁移：HOME 改了但 .ssh 没跟上

现象五：给 PortableGit 指向自定义 HOME 后，ssh 连接远程仓库提示找不到身份文件，或者让输入密码。原因：HOME 变量被改了，git 和 ssh 都去新 HOME 找 .ssh/id_ed25519，但新目录下没有 .ssh 文件夹，密钥不在那里。解决：把整个 .ssh 目录搬过去，同时注意 Windows 上私钥文件的权限要收紧；或者用 core.sshCommand 显式指定密钥路径：

git config --global core.sshCommand "ssh -i D:/portable-git/home/.ssh/id_ed25519"

这个设置只影响 Git 调用 ssh 的方式，不影响系统其他 ssh 使用。如果搬完 .ssh 还是不行，检查一下密钥文件是否带多余的后缀名，OpenSSH 对文件名敏感，多一个字符都不认。还有一件事容易被忽略：.ssh 目录下不能有其他用户可写，否则 OpenSSH 会拒用该密钥，Windows 上表现为权限错误。打开文件属性，把继承权限收紧到只剩当前用户。

5. 多版本共存与配置迁移：把整份环境粘到 U 盘上

5.1 新老版本并存：脚本里用绝对路径调用

V2.35 和其他 Git 新版本完全可以并存。它们各自解压到独立目录，互不干扰，只要 PATH 里只放其中一份，就不会有冲突。全局配置默认共用同一份 $HOME/.gitconfig，如果你想隔离，把 HOME 分开指向两个目录即可。用共享配置也不需要担心格式问题，Git 配置格式向后兼容，老版本读新配置文件可能会有未知字段告警，但基本不影响主流程。

脚本里调用时，不建议依赖 PATH 解析，写绝对路径最稳：

"D:\git235\cmd\git.exe" -C D:\workspace\project status "D:\git\cmd\git.exe" -C D:\workspace\project log -1 --oneline

-C 指定仓库目录，即使当前目录不在仓库里也能正确执行。这个方法也顺便绕开了 PATH 顺序问题，无论系统 PATH 里还有没有别的 Git，脚本都只执行你指定的这一份。我一般会做一个环境变量 GIT235 和 GITNEW 指向两个目录，脚本里写成 $GIT235\cmd\git.exe，路径出现变化时只改变量不改脚本。

切换版本的另一个入口是 git-bash.exe 本身，新老版本的终端窗口完全独立，不会互相干扰。我实际用下来，最省心的方式不是日常频繁切，而是固定一份作为默认，另一份只在特定项目或排查问题时启用。便携版的优势就在于，切版本的成本只是换一个目录，不是卸载重装。

5.2 配置随身走：把 HOME 指到一个 dotfiles 目录

规划一个目录，比如 D:\dev\dotfiles，把 .gitconfig、.ssh、.gitignore_global 放进去。然后在系统环境变量里把 HOME 指向这个目录。注意：HOME 这个变量在 Windows 上默认不存在，系统用的是 USERPROFILE，但 Git Bash 和 OpenSSH 认 HOME。我在多台机器上就是这么干的：解压 PortableGit，改掉 HOME，git 的全局配置、密钥、别名全部复活。

# .gitconfig 片段示例 [user] name = your-name email = your-email [core] autocrlf = true excludesfile = ~/.gitignore_global [alias] co = checkout st = status lg = log --oneline --graph --all -15

这个文件涵盖了用户名、行尾策略、全局忽略文件和最常用的别名。.gitignore_global 里放的是个人通用的忽略规则，比如 .idea、*.suo、Thumbs.db 这类编辑器或系统文件。SSH 方面，把 id_ed25519、id_ed25519.pub、known_hosts 三个文件放进 .ssh 目录，之后连接新主机时 known_hosts 也会自动更新，不用每台机器重新确认指纹。

配置袋里还可以放一个 .bashrc，PortableGit 的 Git Bash 启动时会自动加载用户目录下的 .bashrc。我一般会在里面加几条 PATH 追加和 alias，比如把 PortableGit 的 cmd 目录加进去、定义 ll 这样的简写。这样换机器后，打开终端第一眼看到的提示符都是熟悉的样子，这种细节比大功能更影响使用心情。

5.3 用 init 脚本一键还原 PortableGit 环境

有了上面的配置袋，换到一台新机器只需要三步：解压 PortableGit，把 dotfiles 目录放到位，跑一个 init 脚本。bat 脚本可以写成这样：

@echo off setx HOME "D:\dev\dotfiles" setx PATH "%PATH%;D:\portable-git\cmd" git config --global core.excludesfile "%HOME%\.gitignore_global" echo done

第一行把 HOME 固定到配置袋，第二行把 cmd 加进 PATH，第三行关联全局忽略文件。注意这里用 setx 有 1024 字符风险，严格一点的做法是用之前提到的 PowerShell SetEnvironmentVariable 只改用户作用域。跑完之后重开终端，git --version 和 ssh -T 分别验证配置与连接。ssh -T 的返回信息因托管平台而异，但只要提示认证成功，就说明公钥和私钥配对正常。

这套流程我实际跑过很多次，从解压到全部配置生效，五分钟以内能完成。init 脚本本质上是一份部署清单，它把手动配置过程中容易漏掉的步骤固化下来，避免每次换机器都要重新回忆一遍。脚本本身也会跟着 dotfiles 一起走，U 盘拷到哪都能用。如果你希望更自动化，还可以把 PortableGit 压缩包一起放进 U 盘，整个环境就是目录 + 脚本 + 配置袋三层结构，三层各司其职。

6. 再进一步：用 PortableGit 的 bash 跑一套自包含构建脚本

到了这一步，你已经拥有了一个完全独立的 Git 环境，接下来可以把它当成构建工具链的一部分来用。我经常会写一个自包含的 build.sh，用 PortableGit 的 bash 执行，让脚本不依赖系统是否装了 Git，也不怕系统里的 Git 版本太老、语法不支持。

#!/usr/bin/env bash set -euo pipefail export HOME="D:/dev/dotfiles" export PATH="/d/portable-git/cmd:$PATH" VERSION=$(git describe --tags --always --dirty) echo "build version: $VERSION" # 这里放你的编译、打包、产物输出命令 # 例如用 tar 打包源码目录 tar -czf "dist/$(basename "$PWD")-$VERSION.tar.gz" src/

调用方式固定走 PortableGit 的 bash，不经过系统注册的 git：

D:\portable-git\usr\bin\bash.exe --login D:\workspace\project\build.sh

--login 会让 bash 加载 /etc/profile 和 ~/.bashrc，这样 unix 工具链和自定义 PATH 都齐了。脚本第一行把 PortableGit 的 cmd 目录放在 PATH 最前面，保证脚本内部所有的 git 调用都命中 V2.35，而不是系统里的旧版本。即使系统装了别的 Git，这个脚本也完全不受影响，这就是自包含的含义。

我过去吃过一次亏：在某台机器上跑项目脚本，脚本里直接写 git 命令，系统里装着老版本 Git，解析不了新语法直接崩掉，排查半天才发现调的是系统 Git 而不是项目指定的便携版。从那以后我每次跑构建脚本前，都强制确认 bash.exe 的绝对路径，脚本里也显式把 PortableGit 的 cmd 放在 PATH 第一位。从那以后我每次跑构建脚本前，都强制确认 bash.exe 的绝对路径，脚本里也显式把 PortableGit 的 cmd 放在 PATH 第一位。把这套做法固定下来，构建就再也不受环境差异影响了。希望帮到你。

本文还有配套的精品资源，点击获取