在 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