0

私たちの作業プロセスは次のとおりです。

  1. 開発者は中央リポジトリから複製しています。
  2. 開発者 A はローカルでバグ修正 A に取り組んでおり、ブランチブランチを中央リポジトリbug_aにプッシュしています。bug_a
  3. 開発者 B はローカルでバグ修正 B に取り組んでおり、ブランチブランチを中央リポジトリbug_bにプッシュします。bug_b
  4. 作業が完了すると、ブランチはブランチにマージされdevelopます。

簡単にするために、両方のブランチが共通ファイルに触れていないと仮定しましょう。私たちの要件は、どのファイルとコードが変更されたかを最終的に正確に再構築できることです bug_a。についても同じですbug_b。したがって、のマージのコミットは、このバグ A ソリューションに対して行われた正確な変更bug_aを示しています。develop

ここで疑問が生じます。私は取り組んでおり、私のリポジトリでbug_aの変更を確認したいと考えています。bug_b

ブランチで の変更をプルできることはわかっていますが、最終的なマージ/コミットで の変更も表示され、バグ A を解決するために行われた正確な変更を再構築できないため、要件が満たされてbug_bいません 。bug_adevelopbug_b

私の質問は、他のブランチで行われた変更がローカルの作業ブランチに表示されるコマンドまたはプロシージャが Git にありますか? クリアケースの「ビュー」のように

master
develop
bug_b
*bug_a
4

2 に答える 2

2

いくつかの用語を乱用すると、各 git リポジトリ自体は clearcase のプライベート ビューによく似ています。他の人のビューを直接見ることはできません。(ただし、後で説明するショートカットがあります。)

幸いなことに、2 人は 3 番目の共有レポを持っているため、彼を間接的に見ることができます。彼は共有レポにプッシュし、次にあなたfetch(それpullは答えを複雑にするため、まだ行っていません) を共有レポからプッシュします。fetchこれで、 (デフォルトではとにかく) すべてを取得するため、彼が何をしたかがわかります。

ただし、git が clearcase と大きく異なる点は次のとおりです。git に、それを目に見える場所に抽出するように依頼することで、「彼が何をしたかを見る」ことができます。「ただ現れる」のではなく、「見せてください」と言わなければなりません。

次の 1 つまたは複数の操作を行うことで確認できます。

  • git (または GUI) に差分を表示するように依頼する
  • 現在の作業ツリーに別のブランチをチェックアウトするように git に依頼する (ここでは明らかに衝突の可能性があります)
  • 特定のブランチから 1 つまたは複数の特定のファイルの内容を現在の作業ツリーにチェックアウトするように git に依頼する
  • 別のブランチを別の(おそらく新しい) 作業ツリーにチェックアウトするように git に依頼する

これらはすべて、特定のリビジョンを指定する方法をある程度理解する必要があります (「ブランチ名」またはコミット ID などによって)。次の 2 つの重要な点に注意してください。

  • clone して fetch すると、git はremotes/origin/masterやのような名前のブランチを作成しますremotes/origin/bug_b。
  • リポジトリでローカルに作業する場合、git はmasterや などの名前のブランチを作成しますbug_a。

したがって、 にfetch編集された変更を表示するにはremotes/origin/bug_b、次を使用します。

git log remotes/origin/bug_b

という名前の独自のブランチを持つ必要はなくbug_b、マージやプルなどを行う必要はありません。見たいだけの場合は、リモートブランチに名前を付けるだけです。ブランチで独自の作業を行う場合にのみ、独自のブランチ名が必要ですbug_b。

まだ理解する必要のない深いところがありますが、ときどき戻ってくる必要があります: のようなブランチ名remotes/origin/bug_bは、実際には のような大きな git SHA1 値の 1 つに名前を付けるための象徴的な方法ですae0af6d748b98716f0f72e428728345b828c4067。git が行うことfetchは、新しいファイルやツリーなどをすべて取得し、それらの大きな毛むくじゃらの ID を持つすべてのコミットを取得し、それらすべてをリポジトリに詰め込むことです。次に更新しますremotes/x/y各「リモートブランチ」の「ヒント」を指すラベル。あなたのレポには、誰もがこれまでに行ったことがあるすべてがあり、必要に応じてすぐに利用できます。(場合によっては「多すぎる」ことが判明するため、実際に持っている量を制限する方法がありますが、「すべて」がデフォルトであり、それについて考える方法です)。すべての VOB の完全なコピー. さいわい、git は clearcase よりもスペースと時間の効率が優れています。)

a を実行するとき、git pull実際には 2 つのことを行っています: a git fetch—これが変更をプルするものです—そして (通常) agit mergeです。マージは、「他の誰かが行った作業」と「あなたが行った作業」を組み合わせたものです。bug_b自分のbug_aブランチで作業しているときにボブが行った変更をフェッチするときは、それは望ましくありません。

(オプションで、 git に make git pullmeanのgit fetch後に を指定することもできgit rebaseます。しかし、それも必要ありません。そのままにしておいてくださいgit fetch。)

ここで、そのショートカットについて説明しますgit clone。元の共有リポジトリを使用している場合は、Bob が変更を共有リポジトリに戻すのを待ってからgit push、bug_b変更を確認する必要があります。ただし、Bob が (ssh などを介して) 彼のプライベート リポジトリへの読み取りアクセスを許可した場合は、Bob のリポジトリを代替の「リモート」として追加できます。たとえば、remotes/origin/bug_bこのリモートに名前を付ける代わりに、 を参照してください。で取得できます。ただし、ボブと調整できる場合を除き、これらすべてを気にしないでください。通常は、2 人とも 1 つの共有リポジトリに移動します。remotes/bob/remotes/bob/bug_bgit remote update bobpush

于 2013-05-26T22:58:01.660 に答える