git-worktree に関する Github の投稿を読みました。あの人たちは書く:
というブランチの Git リポジトリで作業しているとします。
feature
ユーザーが で緊急性の高いバグを報告したとしmaster
ます。最初に、新しいブランチでリンクされた作業ツリーを作成し、hotfix
マスターに対して相対的にチェックアウトします […] バグを修正し、ホットフィックスをプッシュし、プル リクエストを作成できます。
feature というブランチに取り組んでいて、master に緊急性の高いバグが報告された場合、私は通常、作業中のものを隠して新しいブランチを作成します。終わったら、仕事を続けることができます。これは非常に単純なモデルです。私は何年もそのように作業してきました。
一方、git-worktree の使用には独自の制限があります。
たとえば、リンクされた 2 つの作業ツリーで同じブランチを同時にチェックアウトすることは許可されていません。これは、一方の作業ツリーでコミットされた変更が他方の作業ツリーの同期を損なう可能性があるためです。
すでに解決済みの問題に対して、なぜより複雑なワークフローを選択するのでしょうか?
git-worktree
事前にできなかったこと、およびこのまったく新しい複雑な機能を正当化するものはありますか?