如果你的 Git 版本低于 2.5 无法使用 worktree，最稳妥的替代方案是用 git stash 暂存 + 分支切换，或者为不同分支克隆独立仓库目录，前者适合临时切换，后者适合长期并行开发。

命令速用版

先确认你的 Git 版本是否真的不支持 worktree：

git `--version`

如果版本低于 2.5，以下是两种替代方案的核心命令：

方案一：stash 暂存 + 分支切换（临时用）

# 暂存当前修改
git stash push -m "正在开发的功能 A"
# 注：若 Git 版本极老报错，改用 git stash save -m "正在开发的功能 A"

# 切换到其他分支
git checkout hotfix-bug

# 处理完后切回原分支并恢复
git checkout feature-a
git stash pop

方案二：克隆独立目录（长期并行用）

# 在同一父目录下克隆多个副本
git clone /path/to/original project-feature-a
git clone /path/to/original project-hotfix

# 每个目录独立 checkout 不同分支
cd project-feature-a
git checkout feature/a

cd ../project-hotfix
git checkout hotfix/bug

为什么会这样

Git worktree 功能是在 Git 2.5 版本引入的，该版本发布于 2015 年。在此之前，Git 的设计模型是一个仓库对应一个工作目录，切换分支时会直接修改工作区文件。

这意味着旧版本 Git 有两个限制：同一时间只能在一个分支上工作，切换分支前必须暂存或提交未完成代码，否则会导致代码丢失。如果想同时查看两个分支的代码，要么重复克隆多个仓库占用大量磁盘空间，要么在同一个目录下反复切换分支打断开发思路。

worktree 的核心价值是允许同一个 Git 仓库创建多个独立工作目录，每个目录对应不同分支，共享同一个.git 仓库对象数据库。旧版本没有这个能力，只能用更原始的方式模拟。

分步处理

第一步：确认 Git 版本和升级可能性

git `--version`

如果输出版本号低于 2.5.0，先确认能否升级。很多生产环境受限于操作系统或公司政策无法升级，这时候才需要用替代方案。

检查点：记录当前版本号，确认升级是否需要管理员权限或影响其他工具。

第二步：根据任务时长选择方案

如果需要切换分支的时间在几小时以内，用 stash 方案。如果需要同时开发超过一天，用多目录克隆方案。

判断依据：stash 方案不需要额外磁盘空间，但无法真正并行；多目录克隆可以真正并行，但每个副本会占用完整磁盘空间。

第三步：stash 方案操作流程

# 1. 查看当前状态
git status

# 2. 暂存所有修改（包括未跟踪文件加-u 参数）
git stash push -u -m "描述当前工作内容"
# 注：若命令报错，尝试 git stash save -u -m "描述当前工作内容"

# 3. 确认暂存成功
git stash list

# 4. 切换到目标分支
git checkout target-branch

# 5. 完成后切回并恢复
git checkout original-branch
git stash pop

回滚提醒：如果 stash pop 出现冲突，不要强制解决，先用 git stash show -p 查看暂存内容，手动合并后再 git stash drop。

第四步：多目录克隆方案操作流程

# 1. 确认原仓库路径
cd /path/to/original
pwd

# 2. 克隆新目录（本地克隆速度快且不占网络带宽）
git clone . ../project-branch-b

# 3. 进入新目录切换分支
cd ../project-branch-b
git checkout branch-b

# 4. 验证两个目录独立
cd /path/to/original
git branch  # 显示原目录分支
cd ../project-branch-b
git branch  # 显示新目录分支

检查点：两个目录的.git 目录是独立的，修改一个目录不会影响另一个。

Git 升级指南

如果条件允许，升级 Git 到 2.5 以上版本是根本解决方案。不同操作系统的升级命令如下：

CentOS/RHEL (yum)

# 安装 EPEL 源（如果需要）
yum install epel-release
# 安装新版 Git
yum install git

Ubuntu/Debian (apt)

# 添加 PPA 源以获取较新版本
add-apt-repository ppa:git-core/ppa
apt update
apt install git

macOS (brew)

brew install git

升级前需要确认：操作系统包管理器提供的 Git 版本、升级是否影响现有 CI/CD 流程、团队成员 Git 版本是否需要统一。

怎么验证是否生效

stash 方案验证

# 查看暂存列表是否有你的记录
git stash list

# 恢复后确认文件状态
git status
# 应该显示你暂存前的修改文件

如果 git stash list 为空或恢复后文件状态不对，说明暂存失败，需要重新操作。

多目录克隆方案验证

# 在两个目录分别执行
git branch

# 修改一个目录的文件，确认另一个目录不受影响
echo "test" >> test.txt
cd ../other-directory
cat test.txt  # 不应该包含刚才的修改

如果两个目录的分支状态独立且文件修改不互相影响，说明方案生效。

常见坑

stash 方案的坑

第一，stash 暂存的是当前工作区状态，如果切换分支后原分支有新提交，恢复时可能产生冲突。解决方式是恢复前先 git pull 更新原分支。

第二，stash 列表默认有数量限制，长期不清理会堆积。定期用 git stash clear 清理已完成的暂存。

第三，未跟踪的文件默认不被 stash 暂存，需要加-u 参数。如果忘记加，切换分支后未跟踪文件会留在工作区造成混乱。

多目录克隆方案的坑

第一，每个克隆目录是独立的仓库，在一个目录提交的代码不会自动同步到另一个目录。需要在每个目录分别 git push 和 git pull。

第二，磁盘空间消耗大。经验上每个副本会占用接近完整项目大小的空间，大项目需要预留足够磁盘余量。

第三，配置文件不同步。每个目录的.git/config 是独立的，如果配置了远程仓库、用户信息等，需要在每个目录单独配置。