Question Définition de "en aval" et "en amont"


J'ai commencé à jouer avec Git et j'ai rencontré les termes «en amont» et «en aval». J'ai déjà vu ça mais je ne les comprends jamais complètement. Que signifient ces termes dans le contexte des MCS (Gestion de la configuration logicielle outils) et le code source?


707
2018-04-29 17:18


origine


Réponses:


En termes de contrôle de la source, vous êtes "en aval"Lorsque vous copiez (clone, checkout, etc) à partir d'un référentiel, les informations ont coulé" en aval "pour vous.

Lorsque vous apportez des modifications, vous voulez généralement les renvoyer "en amont"Donc, ils se retrouvent dans ce référentiel pour que tout le monde tire de la même source travaille avec les mêmes changements.Ceci est principalement un problème social de la façon dont tout le monde peut coordonner leur travail plutôt que d'une exigence technique de contrôle de la source. vos modifications dans le projet principal afin de ne pas suivre les lignes de développement divergentes.

Parfois, vous allez lire à propos des gestionnaires de paquets 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 qu'ils puissent créer un paquet 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 à faire face au même problème dans la prochaine version.


546
2018-04-29 17:36



Quand vous lisez dans git tag page de manuel:

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

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

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

  • tu es tirant de l'amont "otherRepo" ("otherRepo" est "en amont" de vous ", et vous êtes" en aval " pour autreRepo ").
  • tu es pousser vers l'amont ("otherRepo" est toujours "en amont", où l'information retourne maintenant à).

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


La variante DVCS (Distributed Version Control System) est la suivante: vous n'avez aucune idée de ce qui se passe réellement en aval, à côté de votre propre dépôt par rapport aux dépôts à distance que vous avez déclarés.

  • vous savez ce que l'amont est (les repos que vous tirez ou poussez vers)
  • vous ne savez pas ce qui est en aval (les autres reposant ou poussant vers votre repo).

Fondamentalement:

En terme de "flux de données", votre repo est au fond (" en aval ") d'un flux provenant de repos en amont (" pull from ") et revenant à (le même ou autre) repos en amont (" push to ").


Vous pouvez voir une illustration dans le git-rebase page de manuel avec le paragraphe "RECUPERATION DE REBASE EN AMONT":

Cela signifie que vous êtes tirant d'un dépôt "en amont" où un rebasage a eu lieu, et vous (le référentiel "en aval") est bloqué avec la conséquence (beaucoup de commits en double, car la branche rebasée en amont a recréé les commits de la même branche que vous avez localement).

C'est mauvais parce que pour un repo "en amont", il peut y avoir beaucoup les repos en aval (c'est-à-dire les retraits provenant de l'amont, avec la branche rebasée), tous ayant potentiellement à traiter les doubles commits.

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


Note: ceci n'est pas limité aux données.
Cela s'applique également aux paramètres, comme les commandes git (comme les "porcelaines") appellent souvent en interne d'autres commandes git (les "plomberies"). Voir rev-parse page de manuel:

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


193
2018-05-01 07:10



En amont (en lien avec) Suivi

Le terme en amont a également une signification non ambiguë comme vient à la suite d'outils GIT, en particulier par rapport à suivi

Par exemple :

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

imprimera (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 à (si seulement) Suivi de la succursale distante pour cette branche locale. Il va imprimer 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 tirez un référentiel à partir de github, puis envoyez une requête pull, vous en avez certainement au moins deux: origin (votre repo fourchu sur github) et upstream (Le repo sur github vous fourchu à partir de). Ce ne sont que des noms interchangeables, seule l'URL 'git @ ...' les identifie.

Votre .git/configlit:

   [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, @{en amont}La signification de GIT est unique:

c'est 'la branche' (le cas échéant) sur 'dit à distance', qui suit le 'branche actuelle' Sur ton 'référentiel local'. 

C'est la branche que vous allez chercher / tirer chaque fois que vous lancez une plaine git fetch/git pull, sans arguments.

Disons que vous voulez définir l'origine / maître de la branche distante comme la branche de suivi pour la branche principale locale que vous avez extraite. Juste question:

   $ 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 '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 en amont (suivi) référence, utilisée par argument-moins git-pull (1) 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, avec branch.<name>.remote, la en amont branche 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

Quand dans la branche <name>, il indique à git fetch et git quelle télécommande doit aller chercher / pousser à. Il est par défaut à l'origine si aucune télécommande n'est configurée. l'origine est également utilisée si vous n'êtes sur aucune branche.

En amont et pousser (Gotcha)

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

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

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


75
2018-06-05 17:14



C'est un peu de terminologie informelle.

En ce qui concerne Git, tous les autres référentiels sont simplement distants.

En règle générale, en amont est l'endroit où vous avez cloné (l'origine). Downstream est un projet qui intègre votre travail avec d'autres œuvres.

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 pour Ubuntu.


48
2018-04-30 21:06



En amont appelé Nocif

Il y a, hélas, une autre utilisation de «l'amont» que les autres réponses ne permettent pas de faire, à savoir se référer à la relation parent-enfant des commits dans un repo. Scott Chacon dans le Livre Pro Git est particulièrement enclin à 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'un rapide que cela se produit parce que

le commit indiqué par la branche que vous avez fusionnée était directement   en amont de l'engagement que vous êtes sur

Il veut dire que commettre 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 le ref A pour pointer vers commit B. Pourquoi cette direction devrait être appelé "en amont" plutôt que "en aval", ou pourquoi la géométrie d'un tel graphique en ligne droite pure devrait être décrite "directement en amont", est complètement imprécise et probablement arbitraire. (La page de manuel pour git-merge fait un bien meilleur travail d'expliquer cette relation quand il dit que "la 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 "aval" plus tard pour signifier exactement la même chose, quand il parle de réécrire tous les commits enfant d'un commit supprimé:

Vous devez réécrire toutes les validations en aval de 6df76 pour supprimer complètement   ce fichier de votre histoire 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 informelle, et ne doit pas être encouragée, car elle est simplement source de confusion.

Il est parfaitement clair que tout 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 décrit la directionnalité du graphique sans ambiguïté, de sorte que c'est la façon de parler lorsque vous voulez décrire comment les commits se rapportent les uns aux autres dans la géométrie graphique d'un repo. N'utilisez pas "en amont" ou "en aval" de façon lâche 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 git-merge page de manuel, et il me vient à l'esprit que le premier peut être basé sur un malentendu de ce dernier. La page de manuel décrit une situation où l'utilisation de "en amont" est légitime: le transfert rapide se produit souvent lorsque "vous suivez un référentiel en amont, vous n'avez pas effectué de modifications locales, et vous voulez maintenant mettre à jour vers un nouveau 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 dépôt distant; il n'y a pas de référentiel distant dans l'exemple cité par Chacon de l'avance rapide, juste quelques branches créées localement.]


43
2017-09-27 14:21