在 Git 进行代码管理的时候，时常出现这样的场景：当我在 feature 分支开发的时候，突然临时有个紧急的问题需要进行修复或者别的在测试的 feature 有问题需要处理（后续以 other 分支），我不得不暂停当前这个分支：
方法一: 使用 git statsh 将所有的未提交的修改暂时保存起来，等待解决问题之后，切回到之前的分支，然后将对应的 stash 恢复到当前分支下。
方法二：直接 checkout 到 other 分支，然后修复完问题，将 feature 分支修改的东西不提交，然后重新切回。
方法三：直接将修改 commit,然后切到 other 分支处理问题，然后再切回。
其中方法一可能是比较好的解决方案，但是实际使用下来，当需要切换的次数比较频繁的话，应用哪个 stash 就会成为一个头疼的问题。
git worktree 就可以很好的解决这个问题，不过值得注意的是 git worktree 并不是一个新的特性，早在 2.19.2 版本就引入了这个特性。
git worktree
Manage multiple working trees attached to the same repository.
正常情况下如果直接切换分支的话，我们在当前分支的修改会被带到另外的分支上，这就是为什么我们通常需要提交当前分支的修改或者 stash 的原因，当然也你也可以直接在别的目录下直接重新 git clone 也可以规避这个问题。
不过 git clone 只能算一个这种折中的办法，通过 git worktreee 我们就可以为同一个 repo 创建多个不同的目录，达到 git clone 的效果
使用方法
通过 git worktree add <path> 命令就可以创建一个名为 path 的分支:
git worktree add ../hotfix
会在创建一个 hotfix 分支，并且还有一个 hotfix 的目录与当前目录的同级。
然后就可以通过编辑器分别打开这两个目录，然后无干扰的独立开发了。当然你可以可以指定一个已经存在的分支进行开发 git worktree add <path> <branch>。
如果这个 worktree 不需要了，执行 git worktree remove <path> 就可以删除这个目录了。
题外话
截止到现在还 vscode 和 jetbrains 的相关软件还没有支持这个特效，估计后面也不一定会支持。
参考文章
git worktree
在 Git 进行代码管理的时候，时常出现这样的场景：当我在 feature 分支开发的时候，突然临时有个紧急的问题需要进行修复或者别的在测试的
feature有问题需要处理（后续以other分支），我不得不暂停当前这个分支：方法一: 使用
git statsh将所有的未提交的修改暂时保存起来，等待解决问题之后，切回到之前的分支，然后将对应的 stash 恢复到当前分支下。方法二：直接
checkout到other分支，然后修复完问题，将feature分支修改的东西不提交，然后重新切回。方法三：直接将修改
commit,然后切到other分支处理问题，然后再切回。其中方法一可能是比较好的解决方案，但是实际使用下来，当需要切换的次数比较频繁的话，应用哪个
stash就会成为一个头疼的问题。git worktree就可以很好的解决这个问题，不过值得注意的是git worktree并不是一个新的特性，早在 2.19.2 版本就引入了这个特性。git worktree
正常情况下如果直接切换分支的话，我们在当前分支的修改会被带到另外的分支上，这就是为什么我们通常需要提交当前分支的修改或者
stash的原因，当然也你也可以直接在别的目录下直接重新git clone也可以规避这个问题。不过
git clone只能算一个这种折中的办法，通过git worktreee我们就可以为同一个repo创建多个不同的目录，达到git clone的效果使用方法
通过
git worktree add <path>命令就可以创建一个名为path的分支:会在创建一个
hotfix分支，并且还有一个hotfix的目录与当前目录的同级。然后就可以通过编辑器分别打开这两个目录，然后无干扰的独立开发了。当然你可以可以指定一个已经存在的分支进行开发
git worktree add <path> <branch>。如果这个
worktree不需要了，执行git worktree remove <path>就可以删除这个目录了。题外话
截止到现在还 vscode 和 jetbrains 的相关软件还没有支持这个特效，估计后面也不一定会支持。
参考文章
git worktree