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

Question

J'ai commencé à jouer avec Git et j'ai rencontré les termes "en amont" et "en aval". Je les ai déjà vus mais je ne les ai jamais bien compris. Que signifient ces termes dans le contexte des GDS ( outils de gestion de la configuration logicielle ) et du code source?

brian d foy · Accepted Answer

En termes de contrôle de source, vous êtes "en aval" lorsque vous copiez (clonez, extrayez, etc.) à partir d'un référentiel. Les informations vous ont été transmises "en aval".

Lorsque vous apportez des modifications, vous souhaitez généralement les renvoyer "en amont" afin qu'elles soient intégrées à ce référentiel afin que toutes les personnes extraites de la même source travaillent avec les mêmes modifications. Il s’agit principalement d’une question de société: comment chacun peut coordonner son travail plutôt que d’une exigence technique du contrôle à la source Vous souhaitez intégrer vos modifications dans le projet principal afin de ne pas suivre les lignes de développement divergentes.

Parfois, vous en apprendrez davantage sur les gestionnaires de packages ou de versions (les personnes, pas l'outil) qui parlent de la soumission de modifications en "amont". Cela signifie généralement qu'ils doivent ajuster les sources d'origine pour pouvoir créer un package pour leur système. Ils ne veulent pas continuer à faire ces changements, donc s'ils les envoient "en amont" à la source d'origine, ils ne devraient pas avoir à traiter le même problème dans la prochaine version.

VonC · Answer

Lorsque vous avez lu git tag page de manuel :

Un aspect important de git est qu’il est distribué, ce qui signifie qu’il n’ya pas de processus inhérent "en amont" ou "en aval" dans le système.

, cela simplement [signifie qu'il n'y a pas de absolute =.
Ces notions sont toujours relatives entre deux dépôts et dépendent de la façon dont les données sont transmises:

Si "yourRepo" a déclaré "otherRepo" comme distant, alors:

vous êtes tirant de l'amont "otherRepo" ("otherRepo" est "en amont de vous" et vous êtes "en aval pour otherRepo").
vous êtes poussant en amont ("otherRepo" est toujours "en amont", où les informations sont maintenant renvoyées).

Notez le "de" et le "pour": vous n'êtes pas simplement "en aval", vous êtes "en aval à partir de/pour ", d'où l'aspect relatif.

La solution DVCS (Distributed Version Control System) est la suivante: vous n’avez aucune idée de ce qu’est réellement l’aval, à côté de votre propre référentiel par rapport au référentiel distant que vous avez déclaré.

vous savez ce qu'est en amont (le dépôt que vous extrayez ou que vous poussez)
vous ne savez pas de quoi est fait l’aval (les autres pensions sont extraites de ou poussées vers votre repo ).

Fondamentalement:

En terme de " flux de données ", votre référentiel est au bas ("en aval") d'un flux provenant d'un dépôt en amont ("extraire") et revenir à (la même ou à une autre) mise en pension en amont ("Push to").

Vous pouvez voir une illustration dans git-rebase page de manuel avec le paragraphe "RECOUVREMENT À PARTIR DE LA RECUPÉRATION UPSTREAM":

Cela signifie que vous êtes extrait d'un référentiel "en amont" où une réimpression a eu lie, et vous (le référentiel "en aval") est collé à la conséquence (de nombreux validations en double, car la branche a été recréée en amont les commits de la même branche que vous avez localement).

C’est mauvais, car pour un rapport "en amont", il peut y avoir many ] == dépôts en aval (c.-à-d. Des retraits tirés de celui en amont, avec la branche rebasée) , tous ayant potentiellement pour traiter les commises en double.

Encore une fois, avec l'analogie "flux de données", dans un DVCS, une mauvaise commande "en amont" peut avoir un " effet d'ondulation " en aval.

Remarque: cela ne se limite pas aux données.
Ceci s'applique également aux paramètres, car les commandes git (comme celles en "porcelaine") appellent souvent en interne d'autres commandes git (les commandes "de plomberie"). Voir rev-parse page de manuel :

De nombreuses commandes git porcelainish utilisent un mélange de drapeaux (c'est-à-dire des paramètres commençant par un tiret '-') et de paramètres destinés à la commande git rev-list sous-jacente qu'ils utilisent en interne et drapeaux et paramètres pour l'autre commandes qu’ils utilisent en aval de git rev-list. Cette commande est utilisée pour les distinguer.

Peter Host · Answer

En amont (en relation avec) Suivi

Le terme en amont a également une signification non ambiguë en ce qui concerne la suite d'outils GIT, en particulier en ce qui concerne le suivi

Par exemple :

_ $git rev-list --count --left-right "@{upstream}"...HEAD >4 12 _
affichera (la dernière valeur mise en cache de) le nombre de commits derrière (gauche) et devant (droite) de votre branche en cours de travail, par rapport au ( le cas échéant ) suit actuellement la branche distante pour cette branche locale. Il y aura un message d'erreur sinon:
_ >error: No upstream branch found for '' _

Comme cela a déjà été dit, vous pouvez avoir un nombre quelconque de télécommandes pour un référentiel local. Par exemple, si vous créez un référentiel depuis github, puis émettez une "requête d'extraction", vous en avez certainement au moins deux: Origin (votre repo forké sur github) et upstream (le repo sur github que vous avez créé). Ce ne sont que des noms interchangeables, seule l'url 'git @ ...' les identifie.

Votre _.git/config_ se lit comme suit:

_ [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'autre part, la signification de @ {upstream} pour GIT est unique:

c'est 'la branche' (le cas échéant) sur 'dite distante' , laquelle suit la 'branche actuelle' de votre 'référentiel local' .

Il s'agit de la branche à partir de laquelle vous extrayez/tirez chaque fois que vous émettez un _git fetch_/_git pull_ simple, sans arguments.

Supposons que vous souhaitiez définir la branche distante Origin/master comme branche de suivi pour la branche maître locale que vous avez extraite. Juste émettre:

_ $ git branch --set-upstream master Origin/master > Branch master set up to track remote branch master from Origin. _
Ceci ajoute 2 paramètres dans _.git/config_:
_ [branch "master"] remote = Origin merge = refs/heads/master _
maintenant essayer (à condition que la télécommande 'en amont' 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 comme suit:
_ [branch "master"] remote = upstream merge = refs/heads/dev _
git-Push(1) Page du manuel :
_ -u --set-upstream _
Pour chaque branche mise à jour ou poussée avec succès, ajoutez en amont (suivi) une référence, utilisée par git-pull (1) et sans argument. commandes. 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, la branche 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 _
Dans la branche <name>, il dit à git fetch et à git Push quelle télécommande chercher depuis/Push to. La valeur par défaut est Origin si aucune télécommande n'est configurée. Origin est également utilisé si vous n’êtes sur aucune branche.

En amont et Push (Gotcha)

jetez un oeil à git-config(1) Manual Page

_ git config --global Push.default upstream git config --global Push.default tracking (deprecated) _
Ceci afin d’éviter les poussées accidentelles sur des branches que vous n’êtes pas encore prêts à pousser.

hasen · Answer

C'est un peu de terminologie informelle.

En ce qui concerne Git, chaque autre référentiel n’est qu’une télécommande.

En général, en amont, vous avez cloné (l’origine). En aval, tout projet intégrant votre travail à d’autres travaux.

Les termes ne sont pas limités aux référentiels Git.

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

matt · Answer

En amont appelé nocif

Il y a, hélas, un autre usage du mot "en amont" auquel les autres réponses ne parviennent pas ici, à savoir faire référence à la relation parent-enfant de commet dans un repo. Scott Chacon dans le Pro Git book est particulièrement enclin à cela, et les résultats sont malheureux. Ne pas imiter cette façon de parler.

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

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

Il veut dire que commit B est le seul enfant de l'unique enfant de ... de l'unique enfant de commit A, alors pour fusionner B dans A, il suffit de déplacer la référence A au point de commettre B. Pourquoi cette direction devrait être appelé "en amont" plutôt que "en aval", ou pourquoi la géométrie d'un tel graphe rectiligne pur devrait être décrite "directement en amont", est complètement obscure et probablement arbitraire. (La page de manuel de git-merge explique beaucoup mieux cette relation en indiquant que "l'en-tête de la 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 plus tard "en aval" 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 tous les commits en aval de 6df76 pour supprimer complètement ce fichier de votre historique Git.

Au fond, il semble ne pas avoir une idée claire de ce qu'il veut dire par "en amont" et "en aval" lorsqu'il se réfère à l'histoire des commits au fil du temps. Cette utilisation est donc informelle et ne doit pas être encouragée, car elle est source de confusion.

Il est parfaitement clair que chaque engagement (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 une terminologie acceptée et décrit la directionnalité du graphique sans ambiguïté. C'est donc le moyen de parler lorsque vous souhaitez décrire la relation entre les validations dans la géométrie du graphe d'un référentiel. Ne pas utiliser "en amont" ou "en aval" de manière lâche dans cette situation.

[Remarque supplémentaire: j'ai réfléchi à la relation entre la première phrase Chacon que je cite ci-dessus et la page de manuel git-merge. Il me semble que la première peut être basée sur une incompréhension de la dernière. La page de manuel décrit ensuite une situation dans laquelle l'utilisation d '"en amont" est légitime: les transferts rapides se produisent souvent lorsque "vous suivez un référentiel en amont, vous n'avez commis aucune modification locale, et vous souhaitez maintenant effectuer une mise à jour vers une version plus récente." révision en amont. " Alors peut-être que Chacon a utilisé "en amont" parce qu'il l'a vu ici dans la page de manuel. Mais dans la page de manuel, il existe un référentiel distant. l'exemple cité par Chacon concernant le transfert rapide ne contient pas de référentiel distant, mais quelques branches créées localement.]