問題タブ [git-worktree]

バージョン管理に Git を使用する大規模な Scala プロジェクトに取り組んでいます。私のワークフローは、自分のブランチで新機能に取り組み、必要に応じて切り替えることです。コードのさまざまなリリースは、独自のブランチにあります。すべて非常に標準的です。

コードの特定のバージョンのバグを修正する必要がある場合は、正しいブランチに切り替えてバグを修正し、コミットしてから元の場所に戻します。

問題は、git はすぐに別のブランチに切り替えることができますが、コードを再コンパイルする必要があることです。これには数分かかります。次に、バグを修正し、自分のブランチに戻り、もう一度再コンパイルします。これにはさらに数分かかります。Git が非常に高速であるという目的を無効にしているようです。

他の誰かがこれに遭遇しましたか？それを回避する方法はありますか。これは Scala 固有の問題ではないと確信しています (ただし、Scala はコンパイルが非常に遅いですが)。

3年以上後に更新

ここ数年、@djs answer (git-new-workdir) を使用しています。それは私にとって非常にうまくいきました。私はマスター ディレクトリといくつかの他のディレクトリ (運用、次のリリースなど) を持っており、そこで作業を行う必要があるときに切り替えます。オーバーヘッドはほとんどなく、本番環境にすばやく切り替えて、何かをテストしてから、元の作業に戻ることができます。

7年以上後に更新

git-worktreeが git-new-workdir の代わりになるようです。使用するには:

私はgit-new-workdir以前、1つのgitリポジトリに対して2つの作業ツリーを持っていました。これは通常非常にうまく機能しますが、同じブランチが両方の作業ツリーでチェックアウトされている場合、何かをコミットした後に面白い動作が発生します。

• 私は、きれいな作業ツリーと「マスター」の両方から始めます。
• 作業ツリーAで何かをコミットします。

結果：

• 作業ツリーAの「gitstatus」は「clean」を示しています（予想どおり）
• 作業ツリーBの「gitstatus」に突然「変更をコミットする」と表示されます

表示される変更は、Aで行ったコミットの逆です。たとえば、Aのコミットで行が追加された場合、Bの「コミットする変更」はこの行が削除されたことを示します。

ここで何が起きてるの？これはgit-new-workdirの既知の制限ですか？この問題を回避する方法はありますか？または、両方のコピーで同じブランチがチェックアウトされている間は、チェックインを避ける必要がありますか？

また、ここで内部的に何が起こっているのかを理解することにも興味があります（gitの内部についてはほとんど知りません）。

ノート：

git reset--hardAでコミットする前にBにコミットされていない変更がなかった場合、Bで実行するだけで問題を簡単に解決できることがわかりまし た。

ただし、Bにコミットされていない変更があるときにAでコミットすると、実際のコミットされていない変更がコミットからの偽の変更と混ざり合い、それらを解く簡単な方法がないようです。したがって、質問。

git-new-workdir スクリプトを使用してブランチを管理していますが、ブランチが自動的に同期されないようです。3 つのブランチ (master、branchA、branchB) を持つリポジトリがあります。まず、レポを次のように複製しました。

次に、git-new-workdir を使用してブランチを分割します

これで、project、branchA、および branchB ディレクトリができました。他の誰かが私のリポジトリを他のコンピューターから複製し、branchA をチェックアウトし、ファイルを変更し、コミットしてgit push --all.

したがって、branchA を更新する必要があります。そのため、マスター ブランチ ディレクトリから発行するgit pull --allと、すべてのブランチが即座に更新されることを期待していましたが、そうではありませんでした。branchA ディレクトリの変更されたファイルを確認すると、何も変更されていません。

何が間違っていますか？

git worktree最近、次のコマンドを発見しました。

新しい作業ディレクトリは現在のリポジトリにリンクされ、HEAD、インデックスなどの作業ディレクトリ固有のファイルを除くすべてを共有します。

しかし、ドキュメントも示しています

… サブモジュールのサポートは不完全です。スーパープロジェクトを複数回チェックアウトすることはお勧めしません。

何がうまくいかないかについてのさらなる説明なし。

予想される問題について誰かが教えてくれますか? たとえば、サブモジュールに影響を与えない変更に対してのみ、この方法で生成された個別のワークツリーを使用しても問題ありませんか?

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

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

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

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

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

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

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

gitの「新しい」機能を調べていたのはworktree、私が通常直面している問題、つまり複数のブランチで同時に作業する必要性にうまく適合しているように見えるからです（それらのいくつかは短命ですが、他のものは本当に長命です）。

私は通常、 で数時間作業してから、release_a branch何かを修正してからrelease_x branch少し修正する必要がありrelease_h branchます。私は怠け者なので、Intellij を使用して git リポジトリの複数のコピーをセットアップすることになるので、あちこちでブランチを頻繁に切り替える必要はありません。

git のコマンドについて聞いたとき、worktreeまさに私が探していたものだと思いました。単一のレポに複数の作業ディレクトリを持たせる方法です。そして、大きなプラスとして、別のブランチにプルさせるためだけにブランチで何かを変更するたびに、実際にプッシュする必要がなくなることを意味します (たとえば、ホットフィックスの場合)。私はそれらをローカルにマージすることができました。

worktreegitの正しい理解はありますか?

私はそれで遊んでいますが、それが私の目的のためにどのように機能するかを実際に理解することはできません. デフォルトでは、ルートフォルダーにワークツリーが作成されるようですが、git add .同じフォルダーを作成するとコミットに含まれます。

これは、既存のブランチのワークツリーを作成する方法ですmy_branch(現在 @ であると仮定しますmaster)。

だから私の質問は2つあります：

1. 長時間のブランチに複数のワークツリーを適用することは可能ですか/正しいですか、それとも一時的に意味のあることですか?
2. 不要なワークツリーを適切に削除するにはどうすればよいですか?
3. これらのワークツリーは、メインの git リポジトリの内部または外部に存在する必要がありますか?

ありがとう

するとgit worktree list以下のように表示されます。

これは私の作業ディレクトリです (worktree ディレクトリではありません)。どうしてこうなったのか、掃除の仕方がわかりません。試してみましgit worktree pruneたが、何も変わりません。どんな助けでも大歓迎です。どうもありがとう。

IntelliJ の最新バージョンは、git ワークツリーをサポートしていると言っていますが、それを使用する方法を説明している場所が見つからないようです。右下の Git Branches ポップアップにエントリが表示されることを期待していましたが、表示されません。

次の記事にも説明がありません:
機能を発表するブログ投稿
新機能のビデオ

IntelliJ ヘルプとグーグルも役に立たなかった

Git バージョン 2.7.2.0 を使用しています。ワークツリーは 2.5 で導入されました。