Lorsque vous lisez dans la 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 "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-rebase
page 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-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 de paramètres destinés à la git rev-list
commande 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.