[解決済み】git-worktreeは何に使うのでしょうか？

質問

読む Githubのgit-worktreeに関する記事 . と書かれています。

というブランチの Git リポジトリで作業しているとしましょう。 feature で緊急性の高いバグが報告された場合、そのバグは master . まず、新しいブランチを持つリンクされた作業ツリーを作成します。 hotfix バグを修正し、hotfixをプッシュし、プルリクエストを作成することができます。

featureというブランチで作業をしていて、masterに緊急性の高いバグが報告された場合、私は通常、作業中のものを隠して新しいブランチを作成することにしています。それが終われば、作業を続けることができます。これはとてもシンプルなモデルで、私は何年もそうやって作業してきました。

一方、git-worktreeを使うには、それなりの限界があります。

たとえば、リンクされた2つの作業ツリーで同じブランチを同時にチェックアウトすることはできません。一方の作業ツリーでコミットした変更によって、もう一方の作業ツリーが同期しなくなる可能性があるからです。

すでに解決された問題に対して、なぜより複雑なワークフローを選択する必要があるのでしょうか？

について何かありますか？ git-worktree 事前にできなかったことで、このまったく新しい複雑な機能を正当化するのでしょうか？

どのように解決するのか？

私にとっては、git worktree は久しぶりの大きな改善点です。私は企業向けソフトウェア開発に携わっています。そこでは、3年前にリリースしたような古いバージョンを維持しなければならないことが非常によくあります。もちろん、各バージョンにはブランチがあり、簡単に切り替えてバグを修正できるようになっています。しかし、切り替えにはコストがかかります。なぜなら、その間にリポジトリやビルドシステムを完全に再構築してしまうからです。切り替えた場合、IDEはプロジェクトの設定を適応させようとして、おかしくなってしまいます。

worktreeを使えば、そのような絶え間ない再設定を避けることができるのです。worktreeを使って、古いブランチを別々のフォルダーでチェックアウトします。各ブランチには、独立したIDEプロジェクトが用意されています。

もちろん、これまではレポを何度もクローンすることで可能でしたし、私もこれまでそうしてきました。しかし、それはハードディスクのスペースを無駄にし、さらに同じ変更を何度もレポから取得する必要があることを意味します。