283

git-worktree に関する Github の投稿を読みました。あの人たちは書く:

というブランチの Git リポジトリで作業しているとします。featureユーザーが で緊急性の高いバグを報告したとしmasterます。最初に、新しいブランチでリンクされた作業ツリーを作成し、hotfixマスターに対して相対的にチェックアウトします […] バグを修正し、ホットフィックスをプッシュし、プル リクエストを作成できます。

feature というブランチに取り組んでいて、master に緊急性の高いバグが報告された場合、私は通常、作業中のものを隠して新しいブランチを作成します。終わったら、仕事を続けることができます。これは非常に単純なモデルです。私は何年もそのように作業してきました。

一方、git-worktree の使用には独自の制限があります。

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

すでに解決済みの問題に対して、なぜより複雑なワークフローを選択するのでしょうか?

git-worktree事前にできなかったこと、およびこのまったく新しい複雑な機能を正当化するものはありますか?

4

10 に答える 10

282

私にとって、git worktree は長年にわたる最大の改善点です。私はエンタープライズソフトウェア開発の仕事をしています。そこでは、3 年前にリリースしたもののような古いバージョンを維持しなければならないことが非常に一般的です。もちろん、バージョンごとにブランチがあるので、簡単に切り替えてバグを修正できます。ただし、その間にリポジトリを完全に再構築し、システムを構築する可能性があるため、切り替えには費用がかかります。切り替えると、IDE はプロジェクト設定を適応させようとして異常に動作します。

ワークツリーを使用すると、その絶え間ない再構成を回避できます。ワークツリーを使用して、別のフォルダーにある古いブランチをチェックアウトします。ブランチごとに、独立した IDE プロジェクトを取得しました。

もちろん、これは過去にレポを数回複製することで実行できた可能性があり、これがこれまでの私のアプローチでした。ただし、これはハードドライブのスペースを浪費し、さらに悪いことに、リポジトリから同じ変更を何度も取得する必要があることも意味していました。

于 2015-08-11T20:19:49.317 に答える
76

明らかな用途の 1 つは、異なるバージョンの動作(ソースではない)を同時に比較することです。たとえば、異なるバージョンの Web サイトまたは Web ページだけです。

現地で試してみました。

  • ディレクトリを作成しますpage1

  • 内部にディレクトリsrcgit initそれを作成します。

  • 少しのコンテンツでsrc作成してコミットします。page1.html

  • $ git branch ver0

  • $ git worktree add ../V0 ver0

  • srcmaster にさらにテキストを追加してpage1.htmlコミットします。

  • $ git branch sty1

  • ブランチで編集page1.htmlsty1(独自の CSS スタイルを追加)、コミットを追加します。

  • $ git worktree add ../S1 sty1

Web ブラウザーを使用して、これら 3 つのバージョンを同時に開いて表示できるようになりました。

  • ..\page1\src\page1.html // git が現在持っているものは何でも

  • ..\page1\V0\page1.html // 初期バージョン

  • ..\page1\S1\page1.html // 実験的なスタイルのバージョン

于 2015-09-29T17:27:51.877 に答える
33
  1. ファイルシステムに一度に複数のワークツリーが必要/必要になる正当な理由があります。

    • 他の場所で変更を加える必要があるときにチェックアウトされたファイル操作する(例: コンパイル/テスト)

    • 通常の差分ツールによるファイルの差分

    • マージの競合中に、ファイル内の競合を解決しながら、ソース側にあるソース コードをナビゲートしたいことがよくあります。

    • 何度も切り替える必要がある場合は、複数のワークツリーを扱う必要のないチェックアウトと再チェックアウトに無駄な時間がかかります。

    • git stash によるブランチ間の精神的コンテキストの切り替えの精神的コストは、実際には測定できません。一部の人々は、別のディレクトリからファイルを開くだけではなく、スタッシュに精神的なコストがかかることに気付きます。

  2. 「なぜ複数のローカル クローンを作成しないのか」と尋ねる人もいます。「--local」フラグを使用すると、余分なディスク容量の使用について心配する必要がないことは事実です。これ(または同様のアイデア)は、私がこれまでに行ってきたことです。ローカル クローンに対するリンクされたワークツリーの機能上の利点は次のとおりです。

    1. ローカル クローンを使用すると、余分なワークツリー (ローカル クローン内にある) は、オリジンまたは上流のブランチにアクセスできません。クローンの「起点」は、最初のクローンの「起点」と同じではありません。

      • 実行git log @{u}..するgit diff origin/feature/other-featureことは非常に役立ちますが、これらはもはや不可能であるか、より困難です。これらのアイデアは、さまざまな回避策を介してローカルクローンで技術的に可能ですが、実行できるすべての回避策は、リンクされたワークツリーを介してより適切かつ/またはより簡単に実行できます.
    2. ワークツリー間で参照を共有できます。別のローカル ブランチから変更を比較または借用したい場合は、それが可能になりました。

于 2015-09-29T16:44:20.460 に答える
12

tl;dr: 何らかの理由で 2 つの作業ツリーを同時にチェックアウトしたい場合はいつでもgit-worktree、迅速かつスペース効率の良い方法です。

別の作業ツリーを作成すると、リポジトリのほとんどの部分 (つまり.git) が共有されます。つまり、1 つの作業ツリーにいるときにブランチを作成したり、データを取得したりすると、他の作業ツリーからもアクセスできるようになります。テスト スイートをブランチ foo で実行し、クローンを作成するためにどこかにプッシュする必要がなく、レポをローカルでクローンする手間を避けたいとしますgit-worktree。一時的または永久的に別の場所。クローンと同じように、クローンを使い終わったら削除するだけです。クローンへの参照は、しばらくするとガベージ コレクションされます。

于 2015-08-11T20:05:37.270 に答える
10

私はもともと、これらの派手なワークツリーを何に使用できるのか疑問に思った後、この質問に出くわしました。それ以来、私はそれらを自分のワークフローに統合してきました。最初は懐疑的でしたが、非常に役立つことがわかりました。

私はコンパイルにかなりの時間がかかるかなり大きなコードベースで作業しています。私は通常、自分のマシンに現在の開発ブランチと、現在取り組んでいる機能ブランチと、ライブ システムの現在の状態を表すマスター ブランチを持っています。

私にとっての最大の利点の 1 つは、ブランチ (ワークツリー) を切り替えるたびに全体を再コンパイルする必要がないことです。良い副作用は、開発ワークツリーに移動してそこで作業を行い、ディレクトリを現在の機能ブランチのワークツリーに変更してから、最初にプルすることなくリベースできることです。

于 2016-04-22T07:32:19.420 に答える
7

かなり変わったことがあります。同じマシンで Windows と Linux の開発を行っています。Windows ボックス内で Linux を実行している VirtualBox を使用しています。VirtualBox はいくつかの Windows ディレクトリをマウントし、それらを Linux マシン内で直接使用します。これにより、Windows を使用してファイルを管理し、Linux 内でビルドできます。これはクロスプラットフォーム プロジェクトであるため、同じディレクトリ構造から Windows と Linux の両方でビルドされます。

問題は、Linux と Windows のビルド システムが同じディレクトリで使用されると、互いにクラッシュすることです。同じディレクトリ名を使用するライブラリなどをダウンロードするための複雑なビルド手順がいくつかあります。Windows バージョンのビルド システムは Windows 固有のライブラリをダウンロードし、Linux バージョンのビルド システムは Linux 固有のライブラリをダウンロードします。

理想的な世界では、Windows と Linux がディレクトリ内で共存できるようにビルド システムを変更する必要がありますが、今のところ、この問題はワークツリーで対処されています。"Linux" フォルダーは Linux 固有のビルド アーティファクトを生成でき、"Windows" フォルダーは Windows 固有のビルド アーティファクトを生成できます。これは理想的な解決策とは言えませんが、ビルド システムのバグが修正されるのを待つ間、一時しのぎとして利用できます。

確かに、worktree はこのように設計されていません。Windows バージョンと Linux バージョンを別々のブランチに保持する必要がありますが、実際には同じブランチに配置することを望んでいます。それでも、それは仕事をしており、1 日を節約するワークツリーの型破りなケースです。

于 2016-07-18T22:59:57.533 に答える
1

私にとっての新しいプロジェクトで、機能を作成しました。しかし、いくつかの仕様は失敗しました。結果を比較するために、レポmasterを作成しました。work-tree何が問題なのかがわかるまで、実行コードで結果を段階的に比較しました。

于 2016-09-12T06:34:05.753 に答える