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

ソース管理に関しては、リポジトリからコピー（クローン、チェックアウトなど）するときは「ダウンストリーム」です。情報は「下流」に流れました。

変更を加える場合、通常はそれらを「アップストリーム」に送り返して、リポジトリに入れ、同じソースからプルした全員が同じ変更をすべて処理できるようにします。これは主に、ソース管理の技術的要件ではなく、誰もが自分の作業を調整する方法の社会的問題です。変更をメインプロジェクトに取り込み、異なる開発ラインを追跡しないようにします。

「アップストリーム」への変更の送信について話しているパッケージマネージャーまたはリリースマネージャー（ツールではなく人々）について読む場合があります。これは通常、システムのパッケージを作成できるように元のソースを調整する必要があったことを意味します。彼らはそれらの変更を続けたくないので、元のソースに「上流」に送信する場合、次のリリースで同じ問題に対処する必要はありません。

git tagmanページを読むと：

gitの1つの重要な側面は、gitが配布されることです。主に配布されるということは、システムに固有の「上流」または「下流」がないことを意味します。

、それは単純に、絶対的な上流レポまたは下流レポがないことを意味します。
これらの概念は常に2つのリポジトリの間で相対的であり、データの流れ方に依存します。

「yourRepo」が「otherRepo」をリモートとして宣言している場合、次のようになります。

• あなたがされている上流から引っ張って（「上流にある「otherRepo」「otherRepo」からあなた」、そしてあなたは「下流にあるため otherRepo」）。
• あなたは上流にプッシュしています（ "otherRepo"はまだ "上流"であり、情報は今戻る）。

「from」と「for」に注意してください。あなたは単に「下流」ではなく、「下流/から」なので、相対的な側面があります。

DVCS（Distributed Version Control System）の工夫は次のとおりです。実際にダウンストリームが何であるか、自分が宣言したリモートリポジトリに関連する独自のリポジトリのほかに何があるかわかりません。

• あなたは上流が何であるかを知っています（あなたがプルしたりプッシュしたりしているリポジトリ）
• あなたは、下流（他のリポジトリから引っ張ったりするプッシュで作られているのか分からない、あなたのレポ）。

基本的に：

「データのフロー」に関して、あなたのリポジトリは、上流のリポジトリから来て（「プル」）、上流のリポジトリに戻って（同じまたは他の）フロー（「プッシュ」）の最下部（「ダウンストリーム」）にあります。 ）。

git-rebasemanページの「UPSREAM REBASEからの回復」という段落の図を見ることができます。

これは、リベースが行われた「上流」のリポジトリからプルしていることを意味し、あなた（「下流」のリポジトリ）は結果（多くの重複するコミット）で立ち往生しています。ローカルで持っている）。

1つの "上流"リポジトリでは、多くの下流リポジトリ（つまり、リベースのブランチを持つ上流リポジトリからプルされたリポジトリ）が存在する可能性があり、それらすべてが重複するコミットを処理する必要がある可能性があるため、これは悪いことです。

繰り返しになりますが、「データの流れ」と同様に、DVCSでは、1つの悪いコマンド「アップストリーム」がダウンストリームに「波及効果」を持つ可能性があります。

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

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

上流（関連）追跡

用語は、上流 GITツールのスイートに来るとも特に相対的、いくつかの明確な意味を持って追跡

例えば ​​：

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

現在の作業ブランチの後ろ（左）と先（右）のコミット数（最後にキャッシュされた値）を、このローカルブランチの現在リモートブランチを追跡している（存在する場合）と比較して出力します。それ以外の場合は、エラーメッセージが出力されます。

    >error: No upstream branch found for ''

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

あなたの.git/config読み取り：

   [remote "origin"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = git@github.com:myusername/reponame.git
   [remote "upstream"]
       fetch = +refs/heads/*:refs/remotes/upstream/*
       url = git@github.com:authorname/reponame.git

• 一方、GITに対する@ {upstream}の意味は独特です。

これは、「リモートサイド」の「ブランチ」（存在する場合）であり、「ローカルリポジトリ」の「現在のブランチ」を追跡しています。

これは、引数なしで単純なgit fetch/ を発行するたびにフェッチ/プルするブランチですgit pull。

リモートブランチのオリジン/マスターを、チェックアウトしたローカルマスターブランチのトラッキングブランチに設定するとします。ちょうど発行：

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

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

   [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）およびその他のコマンドで使用される上流（追跡）参照を追加します。詳細についてはbranch.<name>.merge、git-config（1）を参照してください。

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

   branch.<name>.merge

定義し、一緒にしてbranch.<name>.remote、上流の特定のブランチについてのブランチ。マージするブランチをgit fetch / git pull / git rebaseに指示し、git pushにも影響を与える可能性があります（push.defaultを参照）。\（...）

   branch.<name>.remote

ブランチ<name>にあるとき、それはgit fetchとgit pushにどのリモートからフェッチする/プッシュするかを伝えます。リモートが構成されていない場合、デフォルトでoriginになります。originは、ブランチにいない場合にも使用されます。

アップストリームとプッシュ（Gotcha）

マニュアルページを見てgit-config(1)ください

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

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

それは少し非公式な用語です。

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

一般的に言えば、上流は（起点）からクローンした場所です。ダウンストリームは、自分の作業を他の作業と統合するプロジェクトです。

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

たとえば、UbuntuはDebianの派生物であるため、DebianはUbuntuのアップストリームです。

有害と呼ばれる上流

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

たとえば、彼は、これが原因で早送りが発生した結果、

マージしたブランチが指すコミットは、現在のコミットのすぐ上流にあった

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

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

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

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

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

[追記：私が先に引用した最初のChacon文とgit-mergemanページの関係について考えていましたが、前者は後者の誤解に基づいているのではないかと思います。manページは、「アップストリーム」の使用が正当である状況を説明するために続きます：早送りは、「アップストリームリポジトリを追跡していて、ローカルの変更をコミットしておらず、新しいバージョンに更新したい場合によく発生します。アップストリームリビジョン。」したがって、おそらくチャコンが「上流」を使用したのは、マンページでそれを見たからです。しかし、manページにはリモートリポジトリがあります。Chaconが引用している早送りの例には、リモートリポジトリはなく、ローカルで作成された2つのブランチしかありません。]

一般に;

• 上流はソースに向かっている
• ダウンストリームはシンクまたは宛先に向かっています

これは、ソース管理システムを含むすべてのツリーのようなシステムに適用されます。