大部份大批采用 Git 的人单厢加进此种方式的语句转换。有时候这只会给你的组织工作业务流程减少小量的开支，但有时候，这可能将是几段伤痛的历经。
让他们用下列那个范例来探讨许多常用的语句转换思路的优劣：
假定你在两个名叫 feature-X的组成部分中组织工作。你才刚辨认出你须要化解两个毫无关系的难题。这无法在 feature-X 组成部分中顺利完成。你须要在两个捷伊组成部分 feature-Y 中顺利完成此项组织工作。
计划1：存贮+ 组成部分
化解此难题最常用的组织工作业务流程可能将如下表所示右图：
暂停组成部分 feature-X 上的组织工作git stashgit checkout -b feature-Y origin/main痛打玩儿，化解 feature-Y 的难题git checkout feature-X 或 git switch -git stash pop竭尽全力在 feature-X 中组织工作优点：此种方式的优点是，对单纯的更动，这是两个十分单纯的组织工作业务流程。它能较好地组织工作，不光是对较大型库房。
优点：采用此组织工作业务流程时，一场根本无法有两个组织工作区。除此之外，依照你的库房的状况，采用存贮是两个麻烦事的各个环节。
计划2：WIP 递交+ 组成部分
那个化解计划和前两个十分相似，但它采用 WIP（已经开始展开的组织工作Work in Progress）递交而并非存贮。当你准备好转换回去，而并非弹出存贮时，
git reset HEAD~1
会展开 WIP 递交，你能民主自由地竭尽全力，就像以后的计划那样，但无法冲破存贮。
暂停组成部分 feature-X 上的组织工作git add -u（实际上加进修正和删掉的文档）git commit -m “WIP”git checkout -b feature-Y origin/master痛打玩儿，化解 feature-Y 的难题git checkout feature-X 或 git switch -git reset HEAD~1优点：对单纯的更动，这是两个单纯的组织工作流，也适合于较大型库房。你不须要采用存贮。
优点：任何时候都根本无法有两个组织工作区。此外，如果你或你的代码审阅者不够谨慎，WIP 递交可能将会合并到最终产品。
采用此组织工作流时，你永远不要想着将
–hard
加进到
git reset
如果你不小心这样做了，你应该能够采用
git reflog
恢复递交，但你最好完全避免此种情况发生，否则你会听到心碎的声音。
计划3：克隆两个新库房
在那个化解计划中，并非创建捷伊组成部分，而是为每个捷伊功能组成部分创建存储库的新克隆。
优点：你能同时在多个组织工作区中组织工作。你不须要
git stash
或者是 WIP 递交。
优点：须要考虑库房的大小，因为这可能将会占用大批磁盘空间（浅层克隆能帮助化解此种情况，但它们可能将并不总是很合适。）此外，你的库房克隆将互不可知。因为他们无法互相追踪，所以你必须手动追踪你的克隆的源库房。如果须要 git 钩子，则须要为每个新克隆设置它们。
方案4：git 组织工作树
要采用此化解计划，你可能将须要了解
git add worktree
如果你不熟悉 Git 中的组织工作树，请不要难过。许多人多年来都对那个概念一无所知。
什么是组织工作树？
将组织工作树视为库房中属于项目的文档。本质上，这是一种组织工作区。你可能将没有意识到你已经在采用组织工作树了。开始采用 Git 时，你将自动获得第两个组织工作树。
$ mkdir /tmp/foo && cd /tmp/foo$ git init$ git worktree list/tmp 0000000[master]
你能在以上代码看到，甚至在第一场递交前你就有了两个组织工作树。接下来去尝试再加进两个组织工作树到你的项目中吧。
加进两个组织工作树
想要加进两个捷伊组织工作树你须要提供:
硬盘上的两个位置两个组成部分名加进哪些组成部分
$ git clone https://github.com/oalders/http-browserdetect.git$ cd http-browserdetect/$ git worktree list/Users/olaf/http-browserdetect 90772ae [master]$ git worktree add ~/trees/oalders/feature-X -b oalders/feature-X origin/master$ git worktree add ~/trees/oalders/feature-Y -b oalders/feature-Y e9df3c555e96b3f1$ git worktree list/Users/olaf/http-browserdetect 90772ae [master]/Users/olaf/trees/oalders/feature-X 90772ae [oalders/feature-X]/Users/olaf/trees/oalders/feature-Y e9df3c5[oalders/feature-Y]
与大多数其他 Git 命令那样，你须要在库房路径下采用此命令。一旦创建了组织工作树，就有了隔离的组织工作环境。Git 库房会跟踪工作树在磁盘上的位置。如果 Git 钩子已经在父库房中设置好了，那么它们也能在组织工作树中采用。
请注意到，每个组织工作树只采用父库房磁盘空间的一小部分。在此种情况下，组织工作树须要只大约三分之一的原始磁盘空间。这这十分适合展开扩展。如果你的库房达到了千兆字节的级别，你就会真正体会到组织工作树对硬盘空间的节省。
$ du -sh /Users/olaf/http-browserdetect2.9M$ du -sh /Users/olaf/trees/oalders/feature-X1.0M
优点：你能同时在多个组织工作区中组织工作。你不须要采用存贮。Git 会跟踪大部份的组织工作树。你不须要设置 Git 钩子。这也比
git clone
更快，并且能节省网络流量，因为你能在飞行模式下执行此操作。你还能更高效地采用磁盘空间，而无需借助于浅层克隆。
优点：这是个须要你额外学习和记忆的新东西，但如果你能养成采用那个功能的习惯，它会给你丰厚的回报。
额外的小技巧
有很多方式能清除组织工作树，最受欢迎的方式是采用 Git 来移除组织工作树：
git worktree remove /Users/olaf/trees/oalders/feature-X
如果你喜欢 RM 大法，你也能用
rm -rf
来删掉组织工作树。
rm -rf /Users/olaf/trees/oalders/feature-X
但，如果执行此操作，则可能将须要采用
git worktree prune
清理大部份剩余的文档。或者你现在能跳过清理，这将在将来的某个时候通过
git gc
自行顺利完成。
注意事项
如果你准备尝试
git worktree
请记住下列几点：
删掉组织工作树并无法删除该组成部分。能在组织工作树中转换组成部分。你无法在多个组织工作树中同时签出同两个组成部分。像其他命令那样，git worktree 须要从库房内运行。你能同时拥有许多组织工作树。要从同两个本地库房签出创建组织工作树，否则它们将互不可知。git rev-parse
最后一点注意：在采用
git worktree
时，库房根所在的位置可能将取决于语句。幸运的是，
git rev parse
能让你区分这两者。
要查找父库房的根目录，请执行下列操作：git rev-parse –git-common-dir要查找你当前所在库房的根目录，请执行：git rev-parse –show-toplevel依照你的须要选择最好的方式
就像很多事情那样，TIMTOWDI（条条大道通罗马theres more than one way to do it）。重要的是你要找到两个适合你须要的组织工作业务流程。你的需求可能将因手头的难题而异。也许你偶尔会辨认出自己将
git worktree
作为版本控制工具箱中的两个方便工具。
