有一种方法可以实现这个,使用
git worktree add
。确保您的Git至少为2.5(以便具有
git worktree
),最好至少为2.15(修复了一个相当严重的添加工作树错误;如果没有修复,添加的工作树通常不应使用超过两周)。
您的IDE可能与
git worktree add
不兼容;我避免使用IDE,因此无法说哪些IDE与之合作,哪些不合作。
假设您有支持添加工作树的Git版本,请使用
git worktree add
创建您的
dev
分支,并将主工作树保留在
master
分支上。或者,将添加的工作树用于主要(master或其他)分支,将主工作树用于
dev
分支。请记住,Git强制每个工作树都有不同的分支选中。
停止使用
git pull
。(这不是绝对必要的,但我建议这样做。)
要从服务器更新您的存储库,请随时使用git fetch
—在任何工作树中没有额外参数。这将获取它们拥有但您没有的任何新提交,并更新您的origin/*
远程跟踪名称。
要更新您的master
分支,请进入master
分支的工作树,然后在命令行上运行git merge
或git merge origin/master
。(如果您最近没有这样做,请先运行git fetch
以便具有最新的origin/master
。)
要更新您的dev
分支,请进入dev
分支的工作树,然后在命令行上运行git merge
或git merge origin/dev
。与之前一样,如果您最近没有运行git fetch
,则可能需要这样做,以使您的origin/master
处于最新状态。
您的IDE可能无法实现命令行的功能。根据IDE的不同,也许可以在每个工作树中运行两份副本。
请记住,
git pull
只是运行 git fetch
然后运行 git merge
(或者
git fetch
然后运行
git rebase
)。是
git checkout
扰乱了你的工作树文件的时间戳。Git 实际上并不使用或需要工作树:这是为了
你而存在的。运行
git checkout
会用其他提交中的文件替换工作树中的文件,同时还会用其他提交中的文件替换索引中的文件;索引副本是 Git 使用和关心的文件。
Git 替换工作树文件是因为它假设您需要从要切换到的分支中获取这些文件。当然,切换回来会再次更新这些工作树文件。所以现在各种文件已经更新了两次,需要重新构建。
当你添加一个新的工作树时,Git实际上添加了三个项目组:
- 为新工作树添加一个新的
HEAD
,以记住当前提交和/或分支是新工作树中的当前提交;
- 为新工作树添加一个索引,Git用于存储下一个可能进行的提交的Git文件;以及
- 新的工作树本身,供您查看和处理文件。
这个工作树只是一个在主仓库工作树之外的目录(或文件夹)。例如,如果您的主仓库位于
~/work/project
,则可以将其移动到
~/work/project/main
,并创建
~/work/project/dev
来保存
dev
分支的工作树。
然而,从根本上说,问题很简单:当您使用
git checkout
时,Git根据需要
替换索引和工作树内容。因此,您需要停止使用
git checkout
。如果您需要两个工作树,请制作两个单独的工作树。
如果您的Git版本过旧,不支持工作树,请创建两个克隆。除了两个克隆不共享分支外,其他所有内容都是相同的。