Pregunta Definición de "aguas abajo" y "aguas arriba"


Empecé a jugar con Git y me he encontrado con los términos "ascendente" y "descendente". Los he visto antes pero nunca los entiendo completamente. ¿Qué significan estos términos en el contexto de SCM (Gestión de configuración de software herramientas) y el código fuente?


707
2018-04-29 17:18


origen


Respuestas:


En términos de control de fuente, eres "río abajo"cuando copias (clones, compras, etc.) desde un repositorio. La información fluye" río abajo "hacia ti.

Cuando haces cambios, generalmente quieres enviarlos de vuelta "río arriba"así que entran en ese repositorio para que todos los que trabajan desde la misma fuente estén trabajando con los mismos cambios. Esto es principalmente un problema social de cómo todos pueden coordinar su trabajo en lugar de un requisito técnico de control de fuente. sus cambios en el proyecto principal, por lo que no está rastreando las líneas de desarrollo divergentes.

Algunas veces leerá sobre los gerentes de paquetes o lanzamientos (las personas, no la herramienta) hablando de enviar cambios a "aguas arriba". Eso generalmente significa que tuvieron que ajustar las fuentes originales para poder crear un paquete para su sistema. No quieren seguir haciendo esos cambios, por lo que si los envían "en sentido ascendente" a la fuente original, no deberían tener que lidiar con el mismo problema en la próxima versión.


546
2018-04-29 17:36



Cuando lees en git tag página man:

Un aspecto importante de git es que se distribuye, y su distribución en gran medida significa que no hay un flujo "ascendente" o "descendente" inherente en el sistema.

, eso simplemente significa que no hay absoluto repo aguas arriba o repo aguas abajo.
Esas nociones son siempre relativas entre dos repos y dependen de la forma en que fluyen los datos:

Si "yourRepo" ha declarado "otherRepo" como remoto, entonces:

  • usted está tirando de corriente arriba "otherRepo" ("otherRepo" es "corriente arriba" de usted ", y usted está" río abajo para otroRepo ").
  • usted está empujando hacia arriba ("otherRepo" sigue siendo "upstream", donde la información ahora vuelve).

Tenga en cuenta el "desde" y "para": no solo está "río abajo", sino que está "aguas abajo" desde / para", de ahí el aspecto relativo.


El giro de DVCS (Sistema de control de versiones distribuidas) es: no tiene idea de lo que ocurre en sentido descendente, además de su repositorio relativo a los repos remotos que ha declarado.

  • usted sabe qué es el flujo ascendente (los repos que está sacando o empujando)
  • usted no sabe de qué está hecho el flujo descendente (los otros repos que tiran o empujan hacia su repo)

Básicamente:

En el término de "flujo de datos", su repositorio se encuentra en la parte inferior (" descendente ") de un flujo procedente de repos ascendente (" extracción desde ") y regresa a (el mismo u otro) repositorio ascendente (" pulsar para ").


Puedes ver una ilustración en el git-rebase página man con el párrafo "RECUPERACIÓN DE UPSTREAM REBASE":

Significa que eres sacando de un repositorio "aguas arriba" donde tuvo lugar una rebase, y usted (el repositorio "en sentido descendente") está atascado con la consecuencia (muchos commits duplicados, porque la rama rebasada upstream recreó las confirmaciones de la misma rama que tiene localmente).

Eso es malo porque para un repositorio "ascendente", puede haber muchos repos indirectos (es decir, repositorios tirando de uno anterior, con la rama redistribuida), todos ellos potencialmente tienen que ocuparse de las confirmaciones duplicadas.

Nuevamente, con la analogía del "flujo de datos", en un DVCS, un comando incorrecto "ascendente" puede tener un "efecto dominó"aguas abajo.


Nota: esto no está limitado a los datos.
También se aplica a los parámetros, como los comandos de git (como los de "porcelana") a menudo llaman internamente otros comandos de git (los de "fontanería"). Ver rev-parse página man:

Muchos comandos de git porcelainish toman una mezcla de banderas (es decir, parámetros que comienzan con un guion "-') y los parámetros destinados para el subyacente git rev-list comando que usan internamente y banderas y parámetros para los otros comandos que utilizan aguas abajo de git rev-list. Este comando se usa para distinguir entre ellos.


193
2018-05-01 07:10



Upstream (relacionado con) Tracking

El termino río arriba también tiene un significado inequívoco como viene en el conjunto de herramientas GIT, especialmente en relación con rastreo

Por ejemplo :

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

imprimirá (el último valor guardado en caché) el número de confirmaciones detrás (izquierda) y adelante (derecha) de su rama de trabajo actual, relativa a (Si alguna) actualmente rastreando la rama remota para esta rama local. De lo contrario, imprimirá un mensaje de error:

    >error: No upstream branch found for ''
  • Como ya se ha dicho, puede tener cualquier número de controles remotos para un repositorio local, por ejemplo, si bifurca un repositorio de github, luego emite una 'solicitud de extracción', sin duda tiene al menos dos: origin (su repositorio bifurcado en github) y upstream (el repositorio de github del que se bifurcó). Esos son solo nombres intercambiables, solo la URL 'git @ ...' los identifica.

Tu .git/configlee:

   [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
  • Por otra parte, @{río arriba}El significado de GIT es único:

es 'la rama' (si hay alguno) en 'dicho remoto', que está rastreando 'rama actual' en tu 'repositorio local'. 

Es la rama que traes / traes cada vez que emite un simple git fetch/git pullsin argumentos

Supongamos que desea configurar el origen / maestro de la rama remota para que sea la rama de seguimiento para la rama principal local que ha desprotegido. Solo problema:

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

Esto agrega 2 parámetros en .git/config :

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

ahora intente (siempre que el control remoto 'ascendente' tenga una rama 'dev')

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

.git/config ahora dice:

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

git-push(1) Página manual :

   -u
   --set-upstream

Por cada rama que esté actualizada o presionada con éxito, agregue aguas arriba (seguimiento) referencia, utilizada por argumento-menos git-pull (1) y otros comandos. Para más información, ver branch.<name>.mergeen git-config (1).

git-config(1) Página manual :

   branch.<name>.merge

Define, junto con branch.<name>.remote, el río arriba rama para la rama dada. Le dice a git fetch / git pull / git rebase qué rama fusionar y también puede afectar a git push (ver push.default).   \   (...)

   branch.<name>.remote

Cuando está en la rama <nombre>, le dice a git fetch y git push a qué control remoto acceder desde / push. Se establece de forma predeterminada en el origen si no se configura ningún control remoto. origen también se utiliza si no está en ninguna rama.

Upstream y Push (Gotcha)

echa un vistazo a git-config(1) Página manual

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

Esto es para evitar empujes accidentales a las ramas que aún no está listo para empujar.


75
2018-06-05 17:14



Esa es una terminología informal.

En lo que concierne a Git, cada otro repositorio es solo un control remoto.

En general, aguas arriba es donde clonaste desde (el origen). Downstream es cualquier proyecto que integra su trabajo con otros trabajos.

Los términos no están restringidos a los repositorios de Git.

Por ejemplo, Ubuntu es un derivado de Debian, por lo que Debian está en la fase inicial de Ubuntu.


48
2018-04-30 21:06



Upstream Llamado Dañino

Hay, por desgracia, otro uso de "aguas arriba" que las otras respuestas aquí no están alcanzando, es decir, referirse a la relación padre-hijo de confirmaciones dentro de un repositorio. Scott Chacon en el Libro Pro Git es particularmente propenso a esto, y los resultados son desafortunados. No imites esta forma de hablar.

Por ejemplo, él dice de una fusión que resulta un avance rápido que esto sucede porque

la confirmación señalada por la rama en la que se fusionó estaba directamente   aguas arriba del compromiso en el que estás

Quiere decir que el compromiso B es el único hijo del único hijo de ... del hijo único del compromiso A, por lo que para unir B en A es suficiente mover el ref A para apuntar al compromiso B. ¿Por qué esta dirección? debería llamarse "aguas arriba" en lugar de "aguas abajo", o por qué la geometría de un gráfico lineal tan puro debería describirse "directamente aguas arriba", es completamente incierto y probablemente arbitrario. (La página del hombre para git-merge hace un trabajo mucho mejor al explicar esta relación cuando dice que "el jefe de rama actual es un ancestro del compromiso nombrado". Ese es el tipo de cosas que Chacón debería haber dicho).

De hecho, el mismo Chacón parece usar "aguas abajo" más tarde para significar exactamente lo mismo, cuando habla de reescribir todos los commits de un commit eliminado:

Debe volver a escribir todas las confirmaciones posteriores a 6df76 para eliminar por completo   este archivo de su historial de Git

Básicamente, parece no tener una idea clara de lo que quiere decir con "ascendente" y "descendente" cuando se refiere a la historia de los compromisos a lo largo del tiempo. Este uso es informal, entonces, y no debe alentarse, ya que es simplemente confuso.

Está perfectamente claro que cada compromiso (excepto uno) tiene al menos un padre, y que los padres de los padres son ancestros; y en la otra dirección, los commits tienen hijos y descendientes. Esa es la terminología aceptada, y describe la direccionalidad del gráfico sin ambigüedades, por lo que esa es la forma de hablar cuando se desea describir cómo se relacionan los commits entre sí dentro de la geometría del gráfico de un repositorio. No utilice "aguas arriba" o "aguas abajo" sin apretar en esta situación.

[Nota adicional: he estado pensando en la relación entre la primera oración de Chacon que cito arriba y la git-merge página de manual, y se me ocurre que el primero puede basarse en una mala comprensión de este último. La página man continúa describiendo una situación en la que el uso de "upstream" es legítimo: el reenvío rápido a menudo ocurre cuando "está rastreando un repositorio upstream, no ha realizado ningún cambio local y ahora desea actualizar a un más nuevo revisión en sentido ascendente ". Entonces, quizás Chacón usó "aguas arriba" porque lo vio aquí en la página del hombre. Pero en la página man hay un repositorio remoto; no hay un repositorio remoto en el citado ejemplo de reenvío rápido de Chacon, solo un par de ramas creadas localmente.]


43
2017-09-27 14:21