Hello,大家好,我是 Sunday。
让我们假设一个场景:
你正在某个分支中处理一个名为“feature”的功能,突然之间需要在主分支(master)中修复一个关键性 bug。
如果没有使用 git worktree,那么你必须:
- 在功能分支(feature)中存储或提交更改
- 切换到主分支(master),在主分支中修复错误,提交修复
- 切换回功能分支,然后取消存储或检出更改。
特别是如果你需要多次来回切换,这就显得很麻烦了。
但是 如果使用了 git worktree 那么整个操作的流程就会变得更加简单。你可以直接拥有 feature 和 master 两个分支的单独工作目录 并且可以分别在不同目录之间完成开发工作,不再需要进行来回切换
使用 git worktree 完成修复工作
假设你目前在 feature 分支上,正在处理项目的开发工作。突然间,你需要在主分支上修复一个错误。
那么此时你可以使用以下命令为主分支创建一个新的工作树(worktree):
git worktree add ../bugfix master
该命令在当前存储库的相对路径 ../bugfix 处创建一个新目录,并在该目录中签出主分支。现在,你可以转到 bugfix 目录并修复 bug:
cd ../bugfix
你在这里进行的任何更改都将在主分支上进行,并不会影响其他分支。一旦完成了bug修复,则可以直接提交你的更改:
git commit -am "修复 bug"
现在,你可以返回到原工作目录并继续在原分支(feature)上完成之前的工作:
cd ../feature
在原分支(feature)中的完成过的代码依然存在,并且你不需要进行额外的存储和切换分支的操作。
这就是使用 git worktree 完成日常工作的操作流程,它 允许我们同时在多个分支上工作,并且每个分支都有自己的工作目录
让我们把整个过程梳理一遍:
## Push 操作
# 从 bugfix 目录提交 bugfix 分支
cd ../bugfix
git push origin master
# 从 feature 目录提交 feature 分支
cd ../feature
git push origin feature
## Merge 操作
# 切换分支到 master
cd ..
git checkout master
# 合并代码到 master
git merge master
# 合并到 feature
git merge feature
## 删除操作
git worktree remove ../bugfix
git worktree remove ../feature
## 将合并后的更改推送到远程仓库
git push origin master
git worktree 带来的其他好处
除了上述场景之外,git worktree 还有很多其他好处:
- 代码审查: 如果你正在审查多个分支的代码,可以在单独的 worktree 中检出每个分支。这样可以快速的在它们之间切换,而无需每次都执行检出的操作。
- 持续集成/部署: 如果你有一个需要同时处理同一存储库的多个分支的 CI/CD ,git worktree 可以让每个分支都在自己的 worktree 中,避免冲突。
- 长时间运行的任务: 如果你有一项长时间运行的任务(例如:测试套件或代码构建),你希望在一个分支上运行该任务的同时继续在另一个分支上工作,可以在一个目录中运行任务并在另一个目录中工作。(好吧,或许我不该告诉大家这个,因为本来这个时间你可以愉快地摸鱼的,哈哈)