web-dev-qa-db-ja.com

「下流」と「上流」の定義

私はGitで遊び始め、「上流」と「下流」という用語に出会いました。私は以前にこれらを見ましたが、それらを完全に理解することはありませんでした。 SCM（ ソフトウェア構成管理 ツール）とソースコードの文脈でこれらの用語はどういう意味ですか？

gitversion-controlversioningterminologydefinitions
804
brendan

ソース管理の観点からは、リポジトリから（クローン、チェックアウトなど）をコピーすると " downstream "になります。情報はあなたに "下流"に流れた。

あなたが変更を加えるとき、あなたはたいていそれらを " upstream "に送り返して彼らがそれをそのリポジトリに入れるようにしたいので、同じソースから引っ張っている誰もがすべて同じ変更を扱っています。これは主に、ソース管理の技術的要件ではなく、全員が自分の作業を調整する方法に関する社会的な問題です。変更をメインプロジェクトに反映させたいので、異なる開発ラインを追跡してはいけません。

時々、パッケージやリリースマネージャ（ツールではなく、人々）が "上流"への変更の提出について話していることを読むでしょう。それは通常彼らが彼らのシステムのためにパッケージを作成することができるように彼らがオリジナルのソースを調整しなければならなかったことを意味します。彼らはそれらの変更を作り続けたくないので、もし彼らがオリジナルのソースに "アップストリーム"でそれらを送るなら、彼らは次のリリースで同じ問題に対処する必要はないはずです。

624
brian d foy

git tagのmanページ を読むと：

Gitの重要な側面の1つは分散されているということです。分散されているということは、システム内に固有の「上流」や「下流」が存在しないことを意味します。

つまり、単純に は絶対アップストリームレポまたはダウンストリームレポがないことを意味します。
これらの概念は常に2つのリポジトリ間で相対的であり、データの流れ方によって異なります。

"yourRepo"が "otherRepo"をリモートのものとして宣言している場合、 ：

  • あなたは 上流から引っ張る "otherRepo"（ "otherRepo"は "上流 from you"であり、あなたは "下流otherRepo"である）。
  • あなたは 上流にプッシュしています （ "otherRepo"はまだ "上流"にあり、情報はここに戻ってきます）。

"from"と "for"に注意してください。あなたは単に "ダウンストリーム"ではなく、 "ダウンストリームfrom/for"であるため、相対的な側面です。

DVCS（Distributed Version Control System）のねじれは次のとおりです。宣言したリモートレポジトリに対する相対的なレポのほかに、実際にはダウンストリームが何であるかわかりません。

  • あなたは上流が何であるかを知っています
  • ダウンストリームが何で構成されているのか（your repoから引き出される、または引き出される他のリポジトリ）はわかりません。

基本的に：

"データの流れ"という用語では、あなたのレポは上流のレポジトリから来る（ "プルする"）そして戻ってくる（同じ、または同じ）他の）上流のレポジトリ（ "Push to"）。

git-rebaseのmanページ に、「UPSREAM REBASEからの回復」という段落の図があります。

それはあなたが リベースが行われた "上流"リポジトリから引っ張っていることを意味します そしてあなた（ "下流"リポジトリ）は結果にとどまっています。ローカルにある同じブランチのコミット）.

1つの "アップストリーム"リポジトリでは、manyダウンストリームリポジトリ（つまり、リベースされたブランチでアップストリームのリポジトリから取得するリポジトリ）が存在する可能性があり、重複したコミットを処理します。

繰り返しますが、「データの流れ」と同じように、DVCSでは、1つの不正なコマンド「アップストリーム」が「波及効果」ダウンストリームを持つことがあります。

注：これはデータに限定されません。
（ "磁器"のような）gitコマンドは内部的に他のgitコマンド（ "配管"のもの）を呼び出すことが多いので、これはパラメータ にも適用されます。 rev-parseのmanページ ：を参照してください。

多くのgit porcelainishコマンドはフラグ（すなわちダッシュ '-'で始まるパラメータ）とそれらが内部で使用する基礎となるgit rev-listコマンド用のパラメータ、および フラグとgit rev-listの下流で使用する他のコマンド用のパラメータを組み合わせます。 。このコマンドはそれらを区別するために使用されます。

217
VonC

アップストリーム（関連する）トラッキング

upstreamという用語は、特にtracking

例えば ​​：

   $git rev-list --count --left-right "@{upstream}"...HEAD
   >4   12

（if anyに対して、現在の作業ブランチの後方（左）および前方（右）のコミット数（最後にキャッシュされた値）を出力-））現在、このローカルブランチのリモートブランチを追跡しています。それ以外の場合、エラーメッセージが出力されます。

    >error: No upstream branch found for ''
  • 既に述べたように、1つのローカルリポジトリに対して任意の数のリモートがある場合があります。たとえば、githubからリポジトリをフォークし、「プルリクエスト」を発行する場合、少なくとも2つがあります：Origin （githubのフォークされたリポジトリ）およびupstream（フォークされたgithubのリポジトリ）。それらは単に交換可能な名前であり、「git @ ...」URLのみがそれらを識別します。

あなたの.git/configreads：

   [remote "Origin"]
       fetch = +refs/heads/*:refs/remotes/Origin/*
       url = [email protected]:myusername/reponame.git
   [remote "upstream"]
       fetch = +refs/heads/*:refs/remotes/upstream/*
       url = [email protected]:authorname/reponame.git
  • 一方、@ {upstream}のGITの意味は一意です：

それは 'the branch'（ある場合）on 'said remote' 'current branch'を 'local repository'で追跡しています。

引数なしでプレーンなgit fetch/git pullを発行するたびに、そこからフェッチ/プルするブランチです。

リモートブランチOrigin/masterを、チェックアウトしたローカルマスターブランチの追跡ブランチに設定するとします。ただ発行する：

   $ git branch --set-upstream  master Origin/master
   > Branch master set up to track remote branch master from Origin.

これにより、.git/configに2つのパラメーターが追加されます：

   [branch "master"]
       remote = Origin
       merge = refs/heads/master

今すぐ試してください（「アップストリーム」リモートに「dev」ブランチがある場合）

   $ git branch --set-upstream  master upstream/dev
   > Branch master set up to track remote branch dev from upstream.

.git/configは次のようになりました：

   [branch "master"]
       remote = upstream
       merge = refs/heads/dev

git-Push(1)マニュアルページ：

   -u
   --set-upstream

最新の、または正常にプッシュされたすべてのブランチについて、引数なしのgit-pull（1）およびその他で使用される上流（追跡）参照を追加しますコマンド。詳細については、git-config（1）のbranch.<name>.mergeを参照してください。

git-config(1)マニュアルページ：

   branch.<name>.merge

branch.<name>.remoteとともに、指定されたブランチのupstreamブランチを定義します。マージするブランチをgit fetch/git pull/git rebaseに通知し、git Pushにも影響を与える可能性があります（Push.defaultを参照）。 \（...）

   branch.<name>.remote

ブランチ<name>の場合、git fetchおよびgit Pushにどのリモートからフェッチするか/プッシュするかを指示します。リモートが設定されていない場合は、デフォルトでOriginになります。 Originは、ブランチにいない場合にも使用されます。

アップストリームおよびプッシュ（Gotcha）

git-config(1) Manual Page を見てください

   git config --global Push.default upstream
   git config --global Push.default tracking  (deprecated)

これは、まだプッシュする準備ができていないブランチへの偶発的なプッシュを防ぐためです。

82
Peter Host

ちょっと非公式な用語です。

Gitに関する限り、他のすべてのリポジトリは単なるリモートです。

一般的に言って、上流はあなたがクローンを作成した場所です（起源）。下流とは、あなたの作品を他の作品と統合するプロジェクトです。

用語はGitリポジトリに限定されません。

たとえば、UbuntuはDebianの派生物なので、DebianはUbuntuの上流にあります。

52
hasen

上流と呼ばれる有害

残念なことに、ここで他の答えが得られていない「上流」の別の使用法があります。すなわち、リポジトリ内のコミットの親子関係を参照することです。 Pro Gitの本のScott Chacon は特にこれを起こしがちで、結果は残念です。この話し方を真似しないでください。

たとえば、彼はマージの結果、早送りが発生したと述べています。

マージしたブランチが指すコミットは、自分が所属するコミットのすぐ上流にあります。

彼は、コミットBがコミットAの唯一の子の...の唯一の子の唯一の子であると言いたいので、BをAにマージするには、ref AをコミットBを指すように移動すれば十分です。 「下流」ではなく「上流」と呼ぶべきであり、なぜそのような純粋な直線グラフの幾何学を「直接上流」で記述すべきかは、完全には不明であり、おそらく任意である。 （git-mergeのmanページは、「現在のブランチヘッドは名前付きコミットの先祖だ」と言ったときに、この関係を説明するためのはるかに優れた仕事をします。それはChaconが言ったべきことです。）

確かに、Chacon自身は、削除されたコミットのすべての子コミットを書き換えることについて話すとき、後に「ダウンストリーム」を使用してまったく同じことを意味するように見えます。

Git履歴からこのファイルを完全に削除するには、6df76から下流のすべてのコミットを書き換える必要があります。

基本的に彼は時間の経過とともにコミットの履歴を参照するとき彼が "上流"と "下流"で何を意味するのか明確な考えを持っていないようです。したがって、この使用は非公式であり、混乱を招くだけなので推奨されません。

すべてのコミット（1つを除く）に少なくとも1つの親があること、そして親の親が祖先であることは明らかです。そして別の方向では、コミットは子供と子孫を持っています。これは一般的な用語であり、グラフの方向性を明確に説明しているため、リポジトリのグラフジオメトリ内でコミットが互いにどのように関連しているかを説明する場合には、これが話し方です。この状況では、「上流」や「下流」をゆるく使用しないでください。

[補足注：私が上で引用した最初のChacon文とgit-mergeのmanページとの関係について考えてきました、そして前者が後者の誤解に基づいているのかもしれません。 "上流"の使用が正当である状況を説明するために、manページは続きます： "あなたが上流のリポジトリを追跡していて、ローカルの変更をコミットしていない、そして今新しいものに更新したいとき"アップストリームリビジョン。」そのため、Chaconは「アップストリーム」を使用していました。なぜなら、彼はmanページでそれを見たからです。しかしmanページにはリモートリポジトリがあります。 Chaconが引用した早送りの例にはリモートリポジトリはなく、ローカルに作成されたブランチが2、3個あります。]

47
matt