git-subtree: en línea en la nube

PROGRAMA:

NOMBRE

git-subtree: fusiona subárboles y divide el repositorio en subárboles

SINOPSIS

git subárbol añadir -P
git subárbol añadir -P
git subárbol tirar -P
git subárbol empujar -P
git subárbol fusionar -P
git subárbol dividir -P [OPCIONES] [ ]

DESCRIPCIÓN

Los subárboles permiten que los subproyectos se incluyan dentro de un subdirectorio del proyecto principal,
opcionalmente incluyendo el historial completo del subproyecto.

Por ejemplo, puede incluir el código fuente de una biblioteca como subdirectorio de su
.

Los subárboles no deben confundirse con los submódulos, que están destinados a la misma tarea. diferente a
submódulos, los subárboles no necesitan construcciones especiales (como archivos .gitmodule o
gitlinks) estar presente en su repositorio y no obligar a los usuarios finales de su repositorio a
hacer algo especial o entender cómo funcionan los subárboles. Un subárbol es solo un subdirectorio
que se puede comprometer, ramificar y fusionar junto con su proyecto de la forma que desee
querer.

Tampoco deben confundirse con el uso de la estrategia de combinación de subárboles. El principal
La diferencia es que, además de fusionar el otro proyecto como subdirectorio, también puede
extraer el historial completo de un subdirectorio de su proyecto y convertirlo en un
proyecto independiente. A diferencia de la estrategia de fusión de subárboles, puede alternar de un lado a otro
entre estas dos operaciones. Si la biblioteca independiente se actualiza, puede
fusionar automáticamente los cambios en su proyecto; si actualiza la biblioteca dentro de su
proyecto, puede "dividir" los cambios nuevamente y fusionarlos nuevamente en la biblioteca
proyecto.

Por ejemplo, si una biblioteca que creó para una aplicación termina siendo útil en otro lugar,
puede extraer su historial completo y publicarlo como su propio repositorio de git, sin
entremezclando accidentalmente el historial de su proyecto de aplicación.

Consejo
Para mantener limpios sus mensajes de confirmación, recomendamos que las personas dividan sus
se compromete entre los subárboles y el proyecto principal tanto como sea posible. Es decir, si tu
realizar un cambio que afecte tanto a la biblioteca como a la aplicación principal, consignarlo en dos
piezas. De esa forma, cuando divida la biblioteca se compromete más tarde, sus descripciones
todavía tendrá sentido. Pero si esto no es importante para ti, no lo es necesario. git
subárbol simplemente omitirá las partes de la confirmación no relacionadas con la biblioteca cuando
lo divide en el subproyecto más tarde.

COMANDOS

add
Crea el subárbol importando su contenido desde el o
y remoto . Se crea un nuevo compromiso automáticamente, uniéndose al
importó el historial del proyecto con el suyo. Con --calabaza, importa solo una confirmación
del subproyecto, en lugar de su historia completa.

unir
Fusionar cambios recientes hasta en el subárbol. Como con normal git
unir, esto no elimina sus propios cambios locales; simplemente fusiona esos cambios en
lo último . Con --calabaza, crea solo una confirmación que contiene todos los
cambios, en lugar de fusionarse en toda la historia.

Si utiliza --calabaza, la dirección de fusión no siempre tiene que ser hacia adelante; usted puede
utilice este comando para retroceder en el tiempo desde la v2.5 a la v2.4, por ejemplo. Si tu fusionas
introduce un conflicto, puede resolverlo de la forma habitual.

recogida
Exactamente como unir, pero paralelos git recogida en que obtiene la referencia dada de la
repositorio remoto especificado.

empuje
Hace un split (ver abajo) usando el suministrado y luego hace un git empuje para empujar
el resultado al repositorio y ref. Esto se puede usar para empujar su subárbol a
diferentes ramas del repositorio remoto.

split
Extraiga una nueva historia sintética del proyecto a partir de la historia del subárbol. los
El nuevo historial incluye solo las confirmaciones (incluidas las fusiones) que afectaron , y
cada una de esas confirmaciones ahora tiene el contenido de en la raíz del proyecto
en lugar de en un subdirectorio. Por lo tanto, la historia recién creada es adecuada para la exportación.
como un repositorio de git separado.

Después de dividir correctamente, se imprime una única identificación de compromiso en stdout. Esta
corresponde a la CABEZA del árbol recién creado, que puede manipular sin embargo
usted quiere.

Se garantiza que las divisiones repetidas de exactamente el mismo historial son idénticas (es decir, a
producir los mismos ID de confirmación). Debido a esto, si agrega nuevas confirmaciones y luego
volver a dividir, las nuevas confirmaciones se adjuntarán como confirmaciones en la parte superior del historial que
generado la última vez, así que git unir y los amigos trabajarán como se esperaba.

Tenga en cuenta que si usa --calabaza cuando se fusiona, normalmente no debería --reunirse con
cuando te separas.

OPCIONES

-q, - silencioso
Suprima los mensajes de salida innecesarios en stderr.

-d, - depuración
Produzca aún más mensajes de salida innecesarios en stderr.

-PAG , --prefijo =
Especifique la ruta en el repositorio al subárbol que desea manipular. Esta opción
es obligatorio para todos los comandos.

-metro , --mensaje =
Esta opción solo es válida para agregar, combinar y extraer (no estoy seguro). Especificar como el
mensaje de confirmación para la confirmación de fusión.

OPCIONES PARA AGREGAR, UNIR, EMPUJAR, TIRAR

--calabaza
Esta opción solo es válida para agregar, combinar y extraer comandos.

En lugar de fusionar todo el historial del proyecto de subárbol, produzca solo una
confirmar que contiene todas las diferencias que desea fusionar, y luego fusionar ese nuevo
comprometerse con su proyecto.

El uso de esta opción ayuda a reducir el desorden de registros. La gente rara vez quiere ver todos los cambios.
que sucedió entre v1.0 y v1.1 de la biblioteca que están usando, ya que ninguno de los
Las versiones provisionales se incluyeron en su solicitud.

Gracias a --calabaza también ayuda a evitar problemas cuando el mismo subproyecto se incluye en varios
veces en el mismo proyecto, o se elimina y luego se vuelve a agregar. En tal caso, no
tiene sentido combinar las historias de todos modos, ya que no está claro qué parte de la
la historia pertenece a qué subárbol.

Además, con --calabaza, puede alternar entre diferentes versiones
de un subárbol, en lugar de estrictamente hacia adelante. git subárbol unir --calabaza siempre se ajusta
el subárbol para que coincida con la confirmación exactamente especificada, incluso si se llega a esa confirmación
requeriría deshacer algunos cambios que se agregaron anteriormente.

Ya sea que use o no --calabaza, los cambios realizados en su repositorio local permanecen intactos
y luego se puede dividir y enviar en sentido ascendente al subproyecto.

OPCIONES PARA SPLIT

--annotate =
Esta opción solo es válida para el comando split.

Al generar un historial sintético, agregue como prefijo para cada confirmación
mensaje. Dado que estamos creando nuevas confirmaciones con el mismo mensaje de confirmación, pero posiblemente
contenido diferente, de las confirmaciones originales, esto puede ayudar a diferenciarlas y
evitar confusion.

Siempre que se divida, debe usar el mismo , o de lo contrario no tienes un
Garantizar que el nuevo historial recreado será idéntico al anterior. Esa voluntad
evitar que la fusión funcione correctamente. git subtree intenta que funcione de todos modos,
especialmente si usa --rejoin, pero es posible que no siempre sea eficaz.

-B , - rama =
Esta opción solo es válida para el comando split.

Después de generar el historial sintético, cree una nueva rama llamada ese
contiene la nueva historia. Esto es adecuado para empujar inmediatamente aguas arriba.
no debe existir ya.

--ignorar-uniones
Esta opción solo es válida para el comando split.

Si utiliza --reunirse con, git subtree intenta optimizar su reconstrucción histórica para
generar solo las nuevas confirmaciones desde la última --reunirse con. --ignorar-unirse desactiva esto
comportamiento, obligándolo a regenerar toda la historia. En un proyecto grande, esto puede
tomar mucho tiempo.

--onto =
Esta opción solo es válida para el comando split.

Si su subárbol se importó originalmente utilizando algo que no sea el subárbol git, su
El historial puede no coincidir con lo que espera el subárbol git. En ese caso, puede especificar el
confirmar id que corresponde a la primera revisión del historial del subproyecto
que se importó a su proyecto, y git subtree intentará construir su historial
desde allí.

Si usaste git subárbol add, nunca debería necesitar esta opción.

--reunirse con
Esta opción solo es válida para el comando split.

Después de dividir, vuelva a fusionar el historial sintético recién creado en su archivo principal.
proyecto. De esa manera, las divisiones futuras pueden buscar solo la parte de la historia que ha sido
agregado desde el más reciente --rejoin.

Si sus confirmaciones divididas terminan fusionadas en el subproyecto de aguas arriba, y luego desea
obtener la última versión ascendente, esto permitirá que el algoritmo de fusión de git tenga más
evitar conflictos inteligentemente (ya que sabe que estas confirmaciones sintéticas ya son parte
del repositorio upstream).

Desafortunadamente, el uso de esta opción da como resultado git log mostrando una copia extra de cada nuevo
commit que fue creado (el original y el sintético).

Si haces todas tus fusiones con --calabaza, no uses --reunirse con cuando te separas, porque
no desea que el historial del subproyecto sea parte de su proyecto de todos modos.

EJEMPLO 1. ADD COMANDO

Supongamos que tiene un repositorio local al que le gustaría agregar un externo
biblioteca del proveedor a. En este caso, agregaremos el repositorio git-subtree como subdirectorio
de su repositorio de git-extensions ya existente en ~ / git-extensions /:

$ git subárbol agregar --prefix = git-subtree --squash \
git: //github.com/apenwarr/git-subtree.git maestro

dominar debe ser una referencia remota válida y puede ser un nombre de rama diferente

Puede omitir el indicador --squash, pero al hacerlo aumentará el número de confirmaciones
incluido en su repositorio local.

Ahora tenemos un ~ / git-extensions / git-subtree directorio que contiene el código del maestro
rama de git: //github.com/apenwarr/git-subtree.git en nuestro repositorio git-extensions.

EJEMPLO 2. EXTRAER A SUBÁRBOL USO COMETER, UNIR Y TIRAR

Usemos el repositorio para el código fuente de git como ejemplo. Primero, obtenga su propia copia
del repositorio git.git:

$ git clon git: //git.kernel.org/pub/scm/git/git.git test-git
$ cd prueba-git

gitweb (commit 1130ef3) se fusionó en git a partir del commit 0a8f4f0, después de lo cual no fue
ya se mantiene por separado. Pero imagina que se ha mantenido por separado y queríamos
para extraer los cambios de git a gitweb desde ese momento, para compartir con el upstream. Tú podrías
hacer esto:

$ git subárbol dividido --prefijo = gitweb --annotate = '(dividir)' \
0a8f4f0 ^ .. --onto = 1130ef3 --reunir \
- rama gitweb-latest
$ gitk gitweb-último
$ empujar git [email protected]: lo que sea / gitweb.git gitweb-latest: master

(Usamos 0a8f4f0 ^ .. porque eso significa "todos los cambios de 0a8f4f0 a la actual
versión, incluida la propia 0a8f4f0. ")

Si gitweb se había fusionado originalmente usando git subárbol add (o una división previa había
ya se ha hecho con --rejoin especificado), entonces puede hacer todas sus divisiones sin tener
para recordar cualquier ID de confirmación extraño:

$ git subárbol dividido --prefijo = gitweb --annotate = '(dividir)' --reunir \
- rama gitweb-latest2

Y puede fusionar los cambios desde el proyecto anterior con la misma facilidad:

$ git extracción de subárbol --prefijo = gitweb \
[email protected]: lo que sea / gitweb.git master

O, usando --calabaza, puedes rebobinar a una versión anterior de gitweb:

$ git subárbol fusionar --prefijo = gitweb --squash gitweb-latest ~ 10

Luego haz algunos cambios:

$ fecha> gitweb / myfile
$ git agregar gitweb / myfile
$ git commit -m 'creó mi archivo'

Y avance rápido de nuevo:

$ git subárbol fusionar --prefijo = gitweb --squash gitweb-latest

Y observe que su cambio aún está intacto:

$ ls -l gitweb / myfile

Y puede dividirlo y ver sus cambios en comparación con el gitweb estándar:

git log gitweb-latest .. $ (división de subárbol de git --prefijo = gitweb)

EJEMPLO 3. EXTRAER A SUBÁRBOL USO BRANCH

Suponga que tiene un directorio de origen con muchos archivos y subdirectorios y desea
extrae el directorio lib en su propio proyecto git. He aquí una forma breve de hacerlo:

Primero, crea el nuevo repositorio donde quieras:

PS
$ git inicializar --bare

De vuelta en su directorio original:

$ git subárbol dividido --prefijo = lib --annotate = "(dividir)" -b dividir

Luego, inserte la nueva rama en el nuevo repositorio vacío:

$ git push split: maestro

Use git-subtree en línea usando los servicios de onworks.net