私は読むGithub の git-worktree の投稿。 あの人たちは書く：
Git リポジトリの というブランチで作業しているときに
feature、ユーザーが で緊急度の高いバグを報告したとしますmaster。まず、master を基準としてチェックアウトされた新しいブランチ でリンクされた作業ツリーを作成しますhotfix[…] バグを修正し、ホットフィックスをプッシュして、プル リクエストを作成できます。
私が feature というブランチで作業していて、master で緊急度の高いバグが報告された場合、私は通常、作業中のものをすべて保管して新しいブランチを作成します。作業が終わったら、作業を続行できます。これは非常にシンプルなモデルで、私は何年もそのように作業してきました。
一方、git-worktree の使用には独自の制限があります。
たとえば、リンクされた 2 つの作業ツリーで同時に同じブランチをチェックアウトすることは許可されていません。これは、一方の作業ツリーでコミットされた変更によって、もう一方の作業ツリーが同期されなくなる可能性があるためです。
すでに解決されている問題に対して、なぜより複雑なワークフローを選択するのでしょうか?
git-worktree事前に実行できなかったことや、この新しい複雑な機能全体を正当化する何かはありますか?
ベストアンサー1
私にとって、git worktree は久しぶりの大きな改善です。私はエンタープライズ ソフトウェア開発に携わっています。そこでは、3 年前にリリースしたような古いバージョンを維持しなければならないことはよくあります。もちろん、各バージョンにブランチがあるので、簡単に切り替えてバグを修正できます。ただし、切り替えにはコストがかかります。その間にリポジトリとビルド システムを完全に再構築する必要があるためです。切り替えると、IDE はプロジェクト設定を適応させようと必死になります。
worktree を使用すると、頻繁な再構成を回避できます。worktree を使用して、古いブランチを別のフォルダーにチェックアウトします。ブランチごとに、独立した IDE プロジェクトが作成されます。
もちろん、過去にはリポジトリを複数回クローンすることでこれを行うこともできましたし、これがこれまでの私のアプローチでした。しかし、それはハードドライブのスペースを無駄にし、さらに悪いことに、リポジトリから同じ変更を複数回取得する必要があることを意味していました。