it-swarm.com.de

Definition von "Downstream" und "Upstream"

Ich habe angefangen mit Git zu spielen und bin auf die Begriffe "Upstream" und "Downstream" gestoßen. Ich habe sie schon einmal gesehen, aber nie richtig verstanden. Was bedeuten diese Begriffe im Kontext von SCMs ( Software Configuration Management Tools) und Quellcode?

843
brendan

In Bezug auf die Quellcodeverwaltung sind Sie "Downstream", wenn Sie aus einem Repository kopieren (klonen, auschecken usw.). Informationen flossen "stromabwärts" zu Ihnen.

Wenn Sie Änderungen vornehmen, möchten Sie diese normalerweise "pstream" zurücksenden, damit sie in dieses Repository gelangen, damit alle Benutzer, die aus derselben Quelle stammen, mit denselben Änderungen arbeiten. Hierbei handelt es sich in erster Linie um eine soziale Frage, wie jeder seine Arbeit koordinieren kann, und nicht um eine technische Anforderung der Quellcodeverwaltung. Sie möchten Ihre Änderungen in das Hauptprojekt übernehmen, damit Sie keine abweichenden Entwicklungslinien verfolgen.

Manchmal lesen Sie etwas über Paket- oder Release-Manager (die Leute, nicht das Tool), die über das Übermitteln von Änderungen an "Upstream" sprechen. Das bedeutet normalerweise, dass sie die Originalquellen anpassen mussten, um ein Paket für ihr System zu erstellen. Sie möchten diese Änderungen nicht fortsetzen. Wenn sie sie also "upstream" an die ursprüngliche Quelle senden, sollten sie sich in der nächsten Version nicht mit demselben Problem befassen müssen.

650
brian d foy

Beim Einlesen von _git tag_ man page :

Ein wichtiger Aspekt von Git ist, dass es verteilt ist. Wenn es weitgehend verteilt ist, gibt es im System kein inhärentes "Upstream" oder "Downstream".

Dies bedeutet einfach , dass es kein absolutes Upstream-Repo oder Downstream-Repo gibt.
Diese Begriffe sind immer relativ zwischen zwei Repos und hängen von der Art des Datenflusses ab:

Wenn "yourRepo" "otherRepo" als Remote deklariert hat, dann :

  • sie ziehen vom Upstream "otherRepo" ("otherRepo" ist "upstream von Sie ", und Sie sind" Downstream für otherRepo ").
  • sie drücken auf den Upstream ("otherRepo" ist immer noch "upstream", auf den die Informationen jetzt zurückgehen).

Beachten Sie das "von" und "für": Sie sind nicht nur "stromabwärts", Sie sind "stromabwärts von/für ", daher der relative Aspekt.


Die Besonderheit von DVCS (Distributed Version Control System) ist: Sie haben keine Ahnung, was Downstream tatsächlich ist, abgesehen von Ihrem eigenen Repo im Verhältnis zu den von Ihnen deklarierten Remote-Repos.

  • sie wissen, was Upstream ist (die Repos, aus denen Sie ziehen oder zu denen Sie pushen)
  • sie wissen nicht, woraus der Downstream besteht (die anderen Repos ziehen aus Ihrem Repo oder drücken auf ihn ).

Grundsätzlich gilt:

In Bezug auf " Datenfluss " befindet sich Ihr Repo am Ende ("Downstream") eines Flusses, der von Upstream-Repos kommt (" ziehen von ") und zurück zu (den gleichen oder anderen) Upstream-Repos (" Push to ").


Sie können eine Illustration in der Manpage git-rebase mit dem Absatz "WIEDERHERSTELLEN VON UPSTREAM REBASE" sehen:

Es bedeutet, dass Sie aus einem "Upstream" -Repo ziehen, in dem ein Rebase stattgefunden hat , und dass Sie (das "Downstream" -Repo) mit der Konsequenz feststecken ( viele doppelte Festschreibungen, da die vorgelagerte Niederlassung die Festschreibungen derselben Niederlassung, die Sie lokal haben, neu erstellt hat.

Das ist schlecht, weil es für ein "Upstream" -Repo viele Downstream-Repos (dh Repos) geben kann alle müssen sich möglicherweise mit den doppelten Commits befassen.

Wiederum kann bei der Analogie "Datenfluss" in einem DVCS ein fehlerhafter Befehl "stromaufwärts" einen " Welligkeitseffekt " stromabwärts haben .


Hinweis: Dies ist nicht auf Daten beschränkt.
Dies gilt auch für Parameter , da Git-Befehle (wie die "Porzellan" -Befehle) häufig intern andere Git-Befehle aufrufen (die "Sanitärbefehle") " Einsen). Siehe _rev-parse_ Manpage :

Viele git porcelainish-Befehle verwenden eine Mischung aus Flags (dh Parametern, die mit einem Bindestrich _-_ beginnen) und Parametern, die für den zugrunde liegenden Befehl _git rev-list_ bestimmt sind, den sie intern verwenden, und Flags und Parameter für die anderen Befehle, die sie nach _git rev-list_ verwenden. Dieser Befehl dient zur Unterscheidung.

223
VonC

Upstream (bezogen auf) Tracking

Der Begriff pstream hat auch eine eindeutige Bedeutung für die Suite der GIT-Tools, insbesondere in Bezug auf tracking

Beispielsweise :

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

gibt (den letzten zwischengespeicherten Wert von) die Anzahl der Festschreibungen hinter (links) und vor (rechts) Ihrem aktuellen Arbeitszweig aus, bezogen auf den (falls vorhanden) aktuell verfolgten Remote branch für diesen lokalen Zweig. Andernfalls wird eine Fehlermeldung ausgegeben:

_    >error: No upstream branch found for ''
_
  • Wie bereits erwähnt, können Sie eine beliebige Anzahl von Fernbedienungen für ein lokales Repository haben. Wenn Sie beispielsweise ein Repository von github ausgeben und dann eine Pull-Anforderung ausgeben, haben Sie mit Sicherheit mindestens zwei: Origin (Ihr gegabeltes Repo auf Github) und upstream (das Repo auf Github, von dem Sie gegabelt haben). Das sind nur austauschbare Namen, nur die 'git @ ...' URL identifiziert sie.

Ihr _.git/config_ lautet:

_   [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
_
  • Andererseits ist die Bedeutung von @ {upstream} für GIT eindeutig:

es ist 'der Zweig' (falls vorhanden) auf 'der entfernten' , der den verfolgt ' aktueller Zweig ' in Ihrem ' lokalen Repository '.

Dies ist der Zweig, den Sie abrufen/ziehen, wenn Sie einen einfachen _git fetch_/_git pull_ ohne Argumente ausgeben.

Angenommen, Sie möchten den fernen Zweig Origin/master als Verfolgungszweig für den lokalen Hauptzweig festlegen, den Sie ausgecheckt haben. Einfach ausgeben:

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

Dies fügt 2 Parameter in _.git/config_ hinzu:

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

Jetzt versuchen (vorausgesetzt, 'Upstream' Remote hat einen 'Dev'-Zweig)

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

_.git/config_ lautet jetzt:

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

git-Push(1) Manual Page:

_   -u
   --set-upstream
_

Fügen Sie für jeden Zweig, der aktuell ist oder erfolgreich gepusht wurde, die Referenz pstream (tracking) hinzu, die von argumentlosen git-pull (1) - und anderen Befehlen verwendet wird. Weitere Informationen finden Sie unter branch.<name>.merge in git-config (1).

git-config(1) Manual Page:

_   branch.<name>.merge
_

Definiert zusammen mit branch.<name>.remote den Zweig pstream für den angegebenen Zweig. Es teilt git fetch/git pull/git rebase mit, welcher Zweig zusammengeführt werden soll und kann sich auch auf git Push auswirken (siehe Push.default).\(...)

_   branch.<name>.remote
_

In der Verzweigung <Name> wird git fetch und git Push mitgeteilt, von welcher Fernbedienung/Push nach abgerufen werden soll. Der Standardwert ist Origin, wenn keine Fernbedienung konfiguriert ist. Origin wird auch verwendet, wenn Sie sich in keinem Zweig befinden.

Upstream und Push (Gotcha)

werfen Sie einen Blick auf git-config(1) Manual Page

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

Dies dient dazu, versehentliche Pushs an Zweige zu verhindern, für die Sie noch nicht bereit sind.

82
Peter Host

Das ist ein bisschen informelle Terminologie.

Für Git ist jedes andere Repository nur ein Remote-Repository.

Im Allgemeinen ist der Ursprung, von dem Sie geklont haben, im Upstream. Downstream ist jedes Projekt, das Ihre Arbeit mit anderen Arbeiten integriert.

Die Bedingungen sind nicht auf Git-Repositorys beschränkt.

Zum Beispiel ist Ubuntu ein Debian-Derivat, daher ist Debian für Ubuntu upstream.

53
hasen

Upstream als schädlich bezeichnet

Leider gibt es eine andere Verwendung von "Upstream", auf die die anderen Antworten hier nicht eingehen, nämlich die Eltern-Kind-Beziehung von Commits innerhalb eines Repos. Scott Chacon im Pro Git-Buch ist dafür besonders anfällig, und die Ergebnisse sind unglücklich. Imitieren Sie diese Art zu sprechen nicht.

Zum Beispiel sagt er von einer Fusion, die einen schnellen Vorlauf zur Folge hat, dass dies passiert, weil

das Commit, auf das der Zweig verweist, in dem Sie zusammengeführt haben, war direkt vor dem Commit, für das Sie sich angemeldet haben

Er möchte sagen, dass Festschreiben B das einzige Kind des einzigen Kindes von ... des einzigen Kindes von Festschreiben A ist. Um B mit A zusammenzuführen, genügt es, den Verweis A so zu verschieben, dass er auf Festschreiben B zeigt. Warum diese Richtung? sollte "stromaufwärts" anstatt "stromabwärts" genannt werden, oder warum die Geometrie eines solchen reinen linearen Graphen "direkt stromaufwärts" beschrieben werden sollte, ist völlig unklar und wahrscheinlich willkürlich. (Die Manpage für git-merge erklärt diese Beziehung viel besser, wenn dort steht, dass "der aktuelle Zweigkopf ein Vorfahr des genannten Commits ist". So etwas hätte Chacon sagen sollen.)

Tatsächlich scheint Chacon selbst später "Downstream" zu verwenden, um genau dasselbe zu bedeuten, wenn er davon spricht, alle untergeordneten Commits eines gelöschten Commits neu zu schreiben:

Sie müssen alle Commits nach 6df76 neu schreiben, um diese Datei vollständig aus Ihrem Git-Verlauf zu entfernen

Im Grunde scheint er keine klare Vorstellung davon zu haben, was er unter "Upstream" und "Downstream" versteht, wenn er sich auf die Geschichte der Commits im Laufe der Zeit bezieht. Diese Verwendung ist also informell und nicht zu empfehlen, da sie nur verwirrend ist.

Es ist völlig klar, dass jedes Commit (außer einem) mindestens ein Elternteil hat und Eltern von Eltern somit Vorfahren sind; und in der anderen Richtung haben Commits Kinder und Nachkommen. Das ist eine akzeptierte Terminologie und beschreibt die Richtung des Diagramms eindeutig. Auf diese Weise können Sie beschreiben, wie Commits innerhalb der Diagrammgeometrie eines Repos zueinander in Beziehung stehen. Verwenden Sie in dieser Situation nicht "Upstream" oder "Downstream".

[Zusätzliche Anmerkung: Ich habe über die Beziehung zwischen dem ersten Chacon-Satz, den ich oben zitiere, und der Manpage git-merge nachgedacht, und mir fällt ein, dass ersterer auf einem Missverständnis des letzteren beruht. In der Manpage wird eine Situation beschrieben, in der die Verwendung von "Upstream" legitim ist: Die schnelle Weiterleitung erfolgt häufig, wenn Sie ein Upstream-Repository verfolgen, keine lokalen Änderungen festgeschrieben haben und jetzt auf ein neueres aktualisieren möchten vorgelagerte Revision. " Vielleicht hat Chacon "Upstream" verwendet, weil er es hier auf der Manpage gesehen hat. In der Manpage gibt es jedoch ein Remote-Repository. In Chacons zitiertem Beispiel für das schnelle Weiterleiten gibt es kein Remote-Repository, nur ein paar lokal erstellte Zweige.]

48
matt