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

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 parviennent dans ce référentiel afin que tout le monde tirant de la même source travaille avec toutes les mêmes modifications. Il s'agit principalement d'une question sociale de savoir comment chacun peut coordonner son travail plutôt que d'une exigence technique de contrôle des sources. Vous souhaitez intégrer vos modifications dans le projet principal afin de ne pas suivre les lignes de développement divergentes.

Parfois, vous lirez des informations sur les gestionnaires de packages ou de versions (les personnes, pas l'outil) qui parlent de soumettre des modifications à "en amont". Cela signifie généralement qu'ils ont dû ajuster les sources d'origine afin de pouvoir créer un package pour leur système. Ils ne veulent pas continuer à apporter ces modifications, 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.

Lorsque vous lisez dans la git tagpage 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 "en amont" ou "en aval" inhérent au système.

, cela signifie simplement qu'il n'y a pas de mise en pension absolue en amont ou en aval.
Ces notions sont toujours relatives entre deux référentiels et dépendent de la façon dont les données circulent:

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

• vous tirez de «otherRepo» en amont («otherRepo» est «en amont de vous», et vous êtes «en aval pour otherRepo»).
• vous poussez vers l'amont ("otherRepo" est toujours "en amont", où les informations remontent maintenant).

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

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

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

Fondamentalement:

En termes de " flux de données ", votre référentiel se situe au bas ("en aval") d'un flux provenant de référentiels amont ("pull from") et retournant vers (le même ou un autre) référentiel amont ("push to" ).

Vous pouvez voir une illustration dans la git-rebasepage de manuel avec le paragraphe "RECUPERATION A PARTIR DE LA REBASE EN AMONT":

Cela signifie que vous tirez d'un référentiel "en amont" où un rebase a eu lieu et que vous (le référentiel "en aval") êtes bloqué avec la conséquence (beaucoup de validations en double, car la branche rebasée en amont a recréé les validations de la même branche que vous avoir localement).

C'est mauvais parce que pour un dépôt "en amont", il peut y avoir de nombreux repos aval (c'est-à-dire des repos tirant du amont, avec la branche rebasée), tous devant potentiellement faire face aux commits en double.

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

Remarque: cela ne se limite pas aux données.
Elle s'applique également aux paramètres , car les commandes git (comme celles "porcelaine") appellent souvent en interne d'autres commandes git (celles "plomberie"). Voir la rev-parsepage 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 de paramètres destinés à la git rev-listcommande sous-jacente qu'ils utilisent en interne et de drapeaux et de paramètres pour les autres commandes qu'ils utilisent en avalgit rev-list . Cette commande est utilisée pour les distinguer.

Suivi en amont (lié à)

Le terme en amont a également une signification non ambiguë en ce qui concerne la suite d'outils GIT, en particulier par rapport à 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 validations derrière (à gauche) et devant (à droite) de votre branche de travail actuelle, par rapport à la branche distante en cours de suivi (le cas échéant ) pour cette branche locale. Sinon, il affichera un message d'erreur:

    >error: No upstream branch found for ''

• Comme cela a déjà été dit, vous pouvez avoir n'importe quel nombre de télécommandes pour un référentiel local, par exemple, si vous créez un référentiel à partir de github, puis émettez une `` demande de pull '', vous en avez très certainement au moins deux: origin(votre repo forké sur github) et upstream(le dépôt sur github dont vous avez bifurqué). Ce ne sont que des noms interchangeables, seule l'url 'git @ ...' les identifie.

Vos .git/configlectures:

   [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

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

c'est «la branche» (le cas échéant) sur «ladite télécommande» , qui suit la «branche actuelle» sur votre «référentiel local» .

C'est la branche à partir de laquelle vous récupérez / tirez chaque fois que vous émettez un git fetch/ git pullsans argument.

Supposons que vous souhaitiez définir l'origine / maître de la branche distante comme branche de suivi pour la branche principale locale que vous avez extraite. Il suffit d'émettre:

   $ 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 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 lit maintenant:

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

git-push(1)Page de manuel :

   -u
   --set-upstream

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

git-config(1)Page de manuel :

   branch.<name>.merge

Définit, conjointement avec branch.<name>.remote, la branche 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 est dans la branche <nom>, il indique à git fetch et git push à quelle télécommande aller / push. Par défaut, il est d'origine si aucune télécommande n'est configurée. origine est également utilisée si vous n'êtes sur aucune branche.

Amont et Push (Gotcha)

jetez un oeil à la git-config(1)page du manuel

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

C'est pour éviter les poussées accidentelles vers des branches que vous n'êtes pas encore prêt à pousser.

C'est un peu de terminologie informelle.

En ce qui concerne Git, tous les autres référentiels ne sont qu'une télécommande.

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

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.

En amont appelé nuisible

Il y a, hélas, une autre utilisation du terme "en amont" que les autres réponses n'abordent pas, à savoir faire référence à la relation parent-enfant des commits au sein d'un référentiel. Scott Chacon dans le livre Pro Git est particulièrement sujet à cela, et les résultats sont regrettables. N'imitez pas 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 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 en A il suffit de déplacer la référence A pour pointer pour valider B. Pourquoi cette direction devrait être appelé "en amont" plutôt que "en aval", ou pourquoi la géométrie d'un tel graphique linéaire pur devrait être décrite "directement en amont", est complètement floue et probablement arbitraire. (La page de manuel pour git-mergeexplique bien mieux cette relation lorsqu'elle dit que "le chef de branche actuel 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 "en aval" plus tard pour signifier exactement la même chose, lorsqu'il parle de réécrire toutes les validations enfants d'une validation supprimée:

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

Fondamentalement, il ne semble pas avoir une idée claire de ce qu'il entend 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 tout simplement déroutante.

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 une terminologie acceptée et décrit la directionnalité du graphique sans ambiguïté, c'est donc la façon de parler lorsque vous voulez décrire comment les commits sont liés les uns aux autres dans la géométrie du graphique d'un dépôt. N'utilisez pas "en amont" ou "en aval" de manière lâche dans cette situation.

[Note supplémentaire: J'ai réfléchi à la relation entre la première phrase Chacon que je cite ci-dessus et la git-mergepage de manuel, et il me semble que la première peut être basée sur une mauvaise compréhension de la seconde. La page de manuel continue à décrire une situation où l'utilisation de "amont" est légitime: l'avance rapide se produit souvent lorsque "vous suivez un référentiel en amont, vous n'avez commis aucune modification locale, et maintenant vous voulez mettre à 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 y a un référentiel distant; il n'y a pas de référentiel distant dans l'exemple cité de Chacon d'avance rapide, juste quelques branches créées localement.]

En général;

• en amont est vers la source
• en aval est vers l'évier ou la destination

Cela s'applique à tous les systèmes arborescents, y compris les systèmes de contrôle de source.