Définition des termes "en aval" et "en amont".

Question

J'ai commencé à jouer avec Git et je suis tombé sur les termes "upstream" et "downstream". Je les avais déjà vus auparavant, mais je ne les avais jamais vraiment compris. Que signifient ces termes dans le contexte des SCMs ( Gestion de la configuration des logiciels ) et le code source ?

Answer 1

En termes de contrôle de source, vous êtes " en aval "lorsque vous copiez (clone, checkout, etc) à partir d'un référentiel. L'information circule " en aval " vers vous.

Quand vous faites des changements, vous voulez généralement les renvoyer " en amont "Ils sont donc placés dans ce dépôt afin que tous ceux qui utilisent la même source travaillent avec les mêmes modifications. Il s'agit principalement d'une question sociale sur la façon dont chacun peut coordonner son travail plutôt que d'une exigence technique du contrôle de source. Vous voulez que vos modifications soient intégrées dans le projet principal afin de ne pas suivre des lignes de développement divergentes.

Parfois, vous lirez que les gestionnaires de paquets ou de versions (les personnes, pas l'outil) parlent de soumettre des changements à "l'amont". Cela signifie généralement qu'ils ont dû ajuster les sources originales afin de pouvoir créer un paquet pour leur système. Ils ne veulent pas continuer à faire ces changements, donc s'ils les envoient "en amont" vers la source originale, ils ne devraient pas avoir à faire face au même problème dans la prochaine version.

Answer 2

Quand vous lisez dans git tag page de manuel :

Un aspect important de git est qu'il est distribué, et être distribué signifie en grande partie qu'il n'y a pas d'"amont" ou d'"aval" inhérent au système.

que simplement signifie qu'il n'y a pas absolu repo amont ou repo aval.
Ces notions sont toujours relatives entre deux repos et dépendent de la façon dont les données circulent :

Si "votreRepo" a déclaré "l'autreRepo" comme étant distant, alors :

• vous êtes tirer à partir de l'amont "otherRepo" ("otherRepo" est "en amont") de vous", et vous êtes "en aval pour autreRepo").
• vous êtes poussée vers l'amont ("otherRepo" est toujours "en amont", là où l'information remonte maintenant).

Notez les mots "de" et "pour" : vous n'êtes pas seulement "en aval", vous êtes "en aval". de/pour ", d'où l'aspect relatif.

---

La particularité du système DVCS (Distributed Version Control System) est que vous n'avez aucune idée de ce qu'est réellement l'aval, à part votre propre dépôt par rapport aux dépôts distants que vous avez déclarés.

• vous savez ce qu'est l'amont (les dépôts d'où vous tirez ou vers lesquels vous poussez)
• vous ne savez pas de quoi est fait l'aval (les autres dépôts tirant de ou poussant vers votre repo ).

En gros :

En termes de " flux de données "Votre dépôt se trouve en bas ("en aval") d'un flux provenant de dépôts en amont ("pull from") et retournant vers (le même ou d'autres) dépôts en amont ("push to").

---

Vous pouvez voir une illustration dans le git-rebase page de manuel avec le paragraphe "RECOUVREMENT DU REBASE UPSTREAM" :

Cela signifie que vous êtes tirer d'un dépôt "amont" où un rebasement a eu lieu et vous (le repo "en aval") êtes coincé avec la conséquence (beaucoup de commits dupliqués, parce que la branche rebasée en amont a recréé les commits de la même branche que vous avez localement).

C'est mauvais car pour un repo "amont", il peut y avoir beaucoup de les dépôts en aval (c'est-à-dire les dépôts qui tirent du dépôt amont, avec la branche rebasée), tous ayant potentiellement à gérer les commits dupliqués.

Toujours dans le cadre de l'analogie avec le "flux de données", dans un DVCS, une mauvaise commande "en amont" peut avoir des répercussions sur l'ensemble du système. effet d'entraînement " en aval.

---

Remarque : cela ne se limite pas aux données.
Il s'applique également aux paramètres Les commandes git (comme les commandes "porcelaine") font souvent appel à d'autres commandes git (les commandes "plomberie"). Voir rev-parse page de manuel :

De nombreuses commandes git porcelainish prennent un mélange de drapeaux (c'est-à-dire des paramètres qui commencent par un tiret ' - ') et des paramètres destinés à l'interface sous-jacente git rev-list qu'ils utilisent en interne et des drapeaux et des paramètres pour les autres commandes qu'ils utilisent en aval de git rev-list . Cette commande permet de les distinguer.

Answer 3

Upstream (en relation avec) Tracking

Le terme en amont a également une signification non ambiguë en ce qui concerne la suite d'outils GIT, notamment par rapport à suivi de

Par exemple :

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

imprimera (la dernière valeur mise en cache de) le nombre de commits derrière (à gauche) et devant (à droite) votre branche de travail actuelle, par rapport à la ( le cas échéant ) suivi actuel de la branche distante pour cette branche locale. Sinon, un message d'erreur sera affiché :

    >error: No upstream branch found for ''

• Comme cela a déjà été dit, vous pouvez avoir n'importe quel nombre de remotes pour un dépôt local, par exemple, si vous bifurquez un dépôt de github, puis émettez une 'pull request', vous en avez très certainement au moins deux : origin (votre repo forked sur github) et upstream (le repo sur github à partir duquel vous avez bifurqué). Ce sont juste des noms interchangeables, seule l'url 'git@...' les identifie.

Votre .git/config lit :

   [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

• D'un autre côté, @{upstream} La signification de GIT est unique :

c'est la branche (le cas échéant) sur "dit à distance qui suit le branche actuelle". sur votre Dépôt local .

C'est la branche à partir de laquelle vous récupérez/tirez chaque fois que vous émettez un message simple. git fetch / git pull sans arguments.

Disons que vous voulez que la branche distante origin/master devienne la branche de suivi de la branche master locale que vous avez extraite. Il suffit de lancer :

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

Cela ajoute 2 paramètres dans .git/config :

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

essayez maintenant (à condition que la branche 'upstream' distante ait une branche 'dev')

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

.git/config se lit maintenant :

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

git-push(1) Page du manuel :

   -u
   --set-upstream

Pour chaque branche qui est à jour ou poussée avec succès, ajoutez en amont (suivi) référence, utilisée par git-pull(1) et d'autres commandes sans argument. Pour plus d'informations, voir branch.<name>.merge dans git-config(1).

git-config(1) Page du manuel :

   branch.<name>.merge

Définit, avec branch.<name>.remote le en amont pour la branche donnée. Il indique à git fetch/git pull/git rebase quelle branche fusionner et peut également affecter git push (voir push.default). \ (...)

   branch.<name>.remote

Lorsqu'il se trouve dans la branche <nom>, il indique à git fetch et à git push à partir de quelle télécommande il faut aller chercher/pousser. Par défaut, il s'agit de origin si aucun distant n'est configuré. origin est également utilisé si vous n'êtes sur aucune branche.

En amont et pousser (Gotcha)

jeter un coup d'œil à git-config(1) Page du manuel

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

Cela permet d'éviter les poussées accidentelles vers des branches que vous n'êtes pas encore prêt à pousser.

Answer 4

C'est un peu de la terminologie informelle.

En ce qui concerne Git, tout autre dépôt n'est qu'un dépôt distant.

De manière générale, l'amont est l'endroit d'où vous avez cloné (l'origine). L'aval est tout projet qui intègre votre travail à d'autres travaux.

Les termes ne sont pas limités aux dépôts Git.

Par exemple, Ubuntu est un dérivé de Debian, donc Debian est en amont d'Ubuntu.

Answer 5

L'amont qualifié de nuisible

Il y a, hélas, une autre utilisation de "upstream" que les autres réponses n'abordent pas, à savoir faire référence à la relation parent-enfant des commits dans un repo. Scott Chacon dans le Livre Pro Git est particulièrement sujet à cela, et les résultats sont malheureux. N'imitez pas cette façon de parler.

Par exemple, il dit à propos d'une fusion résultant d'une avance rapide que cela se produit parce que

le commit pointé par la branche dans laquelle vous avez fusionné était directement en amont du commit sur lequel vous vous trouvez

Il veut dire que le commit B est le seul enfant du seul enfant de ... du seul enfant du commit A, donc pour fusionner B dans A il suffit de déplacer la ref A pour qu'elle pointe vers le commit B. Pourquoi cette direction devrait être appelée "amont" plutôt que "aval", ou pourquoi la géométrie d'un tel graphe en ligne droite pure devrait être décrite "directement en amont", n'est absolument pas clair et probablement arbitraire. (La page de manuel de git-merge explique bien mieux cette relation quand il dit que "la tête de branche actuelle est un ancêtre du commit nommé". C'est le genre de chose que Chacon aurait dû dire).

En effet, Chacon lui-même semble utiliser "downstream" plus tard pour signifier exactement la même chose, quand il parle de réécrire tous les commits enfants d'un commit supprimé :

Vous devez réécrire toutes les commandes en aval de 6df76 pour supprimer complètement ce fichier de votre historique Git

Fondamentalement, il semble ne pas avoir d'idée claire de ce qu'il entend par "en amont" et "en aval" lorsqu'il se réfère à l'histoire des commits dans le temps. Cet usage est donc informel et ne doit pas être encouragé, car il est tout simplement déroutant.

Il est parfaitement clair que chaque commit (sauf un) a au moins un parent, et que les parents des parents sont donc des ancêtres ; et dans l'autre sens, les commits ont des enfants et des descendants. C'est la terminologie acceptée, et elle décrit la directionnalité du graphe sans ambiguïté, donc c'est la façon de parler quand vous voulez décrire comment les commits sont liés les uns aux autres dans la géométrie du graphe d'un repo. N'utilisez pas les termes " en amont " ou " en aval " de manière approximative dans cette situation.

[Note supplémentaire : J'ai réfléchi à la relation entre la première phrase de Chacon que je cite ci-dessus et la phrase suivante git-merge et il me semble que la première pourrait être basée sur une mauvaise compréhension de la seconde. La page de manuel décrit une situation où l'utilisation de "upstream" est légitime : l'avance rapide se produit souvent lorsque "vous suivez un dépôt amont, vous n'avez pas commis de changements locaux, et vous voulez maintenant mettre à jour vers une révision amont plus récente". Donc peut-être Chacon a utilisé "upstream" parce qu'il l'a vu ici dans la page de manuel. Mais dans la page de manuel, il y a un dépôt distant ; il n'y a pas de dépôt distant dans l'exemple de fast-forwarding cité par Chacon, juste un couple de branches créées localement].