Git 工作树性能影响
我刚刚了解了 git worktree 功能。它似乎很适合我的用例：我习惯于使用单独的存储库克隆来执行辅助任务。
我正在一个大型单一仓库中工作，有很多频繁的提交和大量的文件。它是如此之大，以至于许多任务都很慢。特别是 git fetch 和 git Push，但即使 git status 也不再是瞬时的。
因此，git worktree 听起来是个好主意，但如果它以任何明显的方式对性能产生负面影响，那么它绝对不值得。
是否有多个工作树导致 git 性能变差的命令或场景？例如，git fetch 是否需要执行更多操作，从而花费更长的时间？
我现在正在亲自尝试。但要进行精确的性能比较并不容易。例如，很难执行相同的 git fetch 两次。
I've just learned about the git worktree feature. It seems to fit my use-case well: I'm used to having a separate repo clone to do side tasks on.
I'm working in a big monorepo with lots of frequent commits and lots of files. It is so big that many tasks are slow. In particular, git fetch and git push, but even git status is no longer instantaneous.
So, git worktree sounds like a good idea, BUT it is absolutely not worth it if it impacts performance negatively in any noticeable way.
Are there commands or scenarios where multiple worktrees cause git to perform worse? For instance, does git fetch need to do more and thus take longer?
I am trying it out myself right now. But it is not easy to make precise performance comparisons. E.g., it is hard to do the same git fetch twice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Git 中的工作树功能确实不应该以任何有意义的方式对性能产生负面影响。原因是工作树基本上只是独立分支上的另一棵工作树，具有自己的索引和可能的一小组本地配置变量。所有引用和对象都存储在主存储库中并在主存储库中共享，因此无论您使用不使用工作树还是使用一百个工作树，都没有关系。
如果您同时处理多个工作树，则可能会出现性能较差的情况，因为在一个工作树中运行 git status 会逐出有关另一工作树的缓存元数据。但是，无论如何，您都会遇到这个问题，但如果您更改主存储库中的分支，情况会更糟，所以我不认为这是一个严重的问题。
有些人喜欢使用多个工作树，有些人则不喜欢。您可能会发现它是否适合您，但我不会担心它的性能。
The worktree functionality in Git really shouldn't impact performance negatively in any meaningful way. The reason is that the worktree is basically just another working tree on an independent branch with its own index and possibly a small set of local configuration variables. All the references and objects are stored in and shared out of the main repository, so it doesn't matter there whether you use no worktrees or a hundred.
It may happen that if you work out of multiple worktrees at once that you will have worse performance because running
git statusin one worktree would evict cached metadata about the other worktree. However, you'd have that problem anyway but worse if you changed branches in the main repository, so I wouldn't consider that a serious problem.Some people like using multiple worktrees and some don't. You may find it's a good fit for you or not, but I wouldn't worry about it in terms of performance.
我最近发现，与克隆中工作树的数量成正比，
git fetch神秘地变慢了。这看起来已经在 git 2.37 中得到解决。从发行说明来看：
（提交消息中的更多详细信息：https://github.com/git/git/commit/f7400da800）
但是这看起来与 git 版本 <2.37 中的 git fetch 特别相关，因此不会解决您对其他命令速度缓慢的观察结果。
关于：
您可以使用 git fetch --dry-run 来帮助解决此问题。
I recently encountered the observation that
git fetchis mysteriously slower proportionate to the number of worktrees in a clone. This looks to have been addressed in git 2.37.From the release notes:
(More details in the commit message: https://github.com/git/git/commit/f7400da800)
However this looks to be specifically relating to
git fetchin git versions <2.37 so doesn't address your observations about other commands being slow.Regarding:
You can use
git fetch --dry-runto help with this.