¿Qué problema git subtreeresuelve? ¿Cuándo y por qué debería usar esa función?

Leí que se usa para la separación de repositorios . Pero, ¿por qué no crearía simplemente dos repositorios independientes en lugar de unir dos no relacionados en uno?

Este tutorial de GitHub explica cómo realizar fusiones de subárboles de Git .

Sé cómo usarlo, pero no cuándo (casos de uso) y por qué , y cómo se relaciona git submodule. Usaría submódulos cuando tengo una dependencia en otro proyecto o biblioteca.

Debe tener cuidado de anotar explícitamente de qué está hablando cuando usa el término 'subárbol' en el contexto de, gitya que en realidad hay dos temas separados pero relacionados aquí:

Estrategia de fusión de git-subtree y git subtree .

El TL; DR

Ambos conceptos relacionados con los subárboles le permiten gestionar de forma eficaz varios repositorios en uno. A diferencia de git-submodule, donde solo los metadatos se almacenan en el repositorio raíz, en forma de .gitmodules , y debe administrar los repositorios externos por separado.

Más detalles

La estrategia de fusión de subárboles de git es básicamente el método más manual que utiliza los comandos a los que hizo referencia.

git-subtree es un script de shell contenedor para facilitar una sintaxis más natural. En realidad, esto sigue siendo parte de contribgit y no está completamente integrado en las páginas de manual habituales. En cambio, la documentación se almacena junto con el script.

Aquí está la información de uso:

NAME
----
git-subtree - Merge subtrees together and split repository into subtrees


SYNOPSIS
--------
[verse]
'git subtree' add   -P <prefix> <commit>
'git subtree' add   -P <prefix> <repository> <ref>
'git subtree' pull  -P <prefix> <repository> <ref>
'git subtree' push  -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]

Me he encontrado con una buena cantidad de recursos sobre el tema de los subárboles, ya que estaba planeando escribir una publicación de blog propia. Actualizaré esta publicación si lo hago, pero por ahora aquí hay información relevante para la pregunta en cuestión:

Mucho de lo que está buscando se puede encontrar en este blog de Atlassian de Nicola Paolucci, la sección correspondiente a continuación:

¿Por qué utilizar subárbol en lugar de submódulo?

Hay varias razones por las que puede que le resulte subtreemejor utilizar:

• La gestión de un flujo de trabajo sencillo es sencilla.
• gitSe admiten versiones anteriores de (incluso antes v1.5.2).
• El código del subproyecto está disponible justo después clonede que se realiza el superproyecto.
• subtreeno requiere que los usuarios de su repositorio aprendan nada nuevo, pueden ignorar el hecho de que está utilizando subtreepara administrar dependencias.
• subtreeno agrega nuevos archivos de metadatos como lo submoduleshace (es decir .gitmodule).
• El contenido del módulo se puede modificar sin tener una copia de repositorio separada de la dependencia en otro lugar.

En mi opinión, los inconvenientes son aceptables:

• Debe aprender sobre una nueva estrategia de fusión (es decir subtree).
• Contribuir con el código upstreampara los subproyectos es un poco más complicado.
• La responsabilidad de no mezclar código de superproyecto y subproyecto en las confirmaciones recae en usted.

También estaría de acuerdo con gran parte de esto. Recomendaría consultar el artículo ya que trata sobre algunos usos comunes.

Es posible que haya notado que también ha escrito un seguimiento aquí donde menciona un detalle importante que se deja fuera de este enfoque ...

git-subtree ¡actualmente no incluye el control remoto!

Esta miopía probablemente se deba al hecho de que las personas a menudo agregan un control remoto manualmente cuando se trata de subárboles, pero esto tampoco se almacena en git. El autor detalla un parche que ha escrito para agregar estos metadatos al compromiso que git-subtreeya genera. Hasta que esto se convierta en la línea principal oficial de git, puede hacer algo similar modificando el mensaje de confirmación o almacenándolo en otra confirmación.

También encuentro esta publicación de blog muy informativa. El autor agrega un tercer método de subárbol que llama git-streea la mezcla. Vale la pena leer el artículo ya que hace un buen trabajo comparando los tres enfoques. Da su opinión personal de lo que le gusta y lo que no le gusta y explica por qué creó el tercer enfoque.

Extras

• enumerando git-subtrees
• Separar subdirectorio

Pensamientos finales

Este tema muestra tanto el poder gitcomo la segmentación que puede ocurrir cuando una característica simplemente no da en el blanco.

Personalmente, he creado un disgusto por lo git-submoduleque me resulta más confuso de entender para los contribuyentes. También prefiero mantener TODAS mis dependencias administradas dentro de mis proyectos para facilitar un entorno fácilmente reproducible sin tratar de administrar múltiples repositorios. git-submodule, sin embargo, es mucho más conocido en la actualidad, por lo que obviamente es bueno estar al tanto y dependiendo de su audiencia, eso puede influir en su decisión.

En primer lugar: creo que su pregunta tiende a obtener respuestas fuertemente obstinadas y puede considerarse fuera de tema aquí. Sin embargo, no me gusta esa política de SO y empujaría el límite de estar en el tema un poco hacia afuera, así que me gusta responder y espero que otros también lo hagan.

En el tutorial de GitHub que señaló, hay un enlace a Cómo usar la estrategia de fusión de subárboles que brinda un punto de vista sobre las ventajas / desventajas:

Comparación de la fusión de subárboles con submódulos

El beneficio de usar la combinación de subárboles es que requiere menos carga administrativa de los usuarios de su repositorio. Se trabaja con más edad (antes de Git) v1.5.2 clientes y tiene el código justo después de clon.

Sin embargo, si utiliza submódulos , puede optar por no transferir los objetos del submódulo . Esto puede ser un problema con la combinación de subárboles.

Además, en caso de que realice cambios en el otro proyecto, es más fácil enviar cambios si solo usa submódulos.

Aquí está mi punto de vista basado en lo anterior:

A menudo trabajo con personas (= confirmadores) que no son usuarios habituales de git, algunos todavía (y siempre) tendrán problemas con el control de versiones. Educarlos sobre cómo usar la estrategia de fusión de submódulos es básicamente imposible. Implica los conceptos de controles remotos adicionales, sobre la fusión, las ramificaciones y luego mezclar todo en un solo flujo de trabajo. Tirar de aguas arriba y empujar aguas arriba es un proceso de dos etapas. Dado que las ramas son difíciles de entender para ellos, todo esto es inútil.

Con los submódulos todavía es demasiado complicado para ellos ( suspiro ) pero es más fácil de entender: es solo un repositorio dentro de un repositorio (están familiarizados con la jerarquía) y puedes empujar y tirar como de costumbre.

Proporcionar scripts de contenedor simples es más fácil en mi humilde opinión para el flujo de trabajo del submódulo.

Para grandes super-repositorios con muchos sub-repositorios, el punto de elegir no clonar datos de algunos sub-repositorios es una ventaja importante de los submódulos. Podemos limitar esto en función de los requisitos de trabajo y el uso de espacio en disco.

El control de acceso puede ser diferente. Todavía no he tenido este problema, pero si diferentes repositorios requieren diferentes controles de acceso, prohibiendo efectivamente a algunos usuarios de algunos sub-repositorios, me pregunto si eso es más fácil de lograr con el enfoque de submódulo.

Personalmente, estoy indeciso sobre qué usar. Entonces comparto tu confusión: o]

Un caso de uso real que tenemos donde git subtree fue una salvación:

El producto principal de nuestra empresa es altamente modular y desarrollado en varios proyectos en repositorios separados. Todos los módulos tienen su hoja de ruta separada. Todo el producto se compone de todos los módulos de versiones de hormigón.

En paralelo, la versión concreta de todo el producto se personaliza para cada uno de nuestros clientes: ramas separadas para cada módulo. La personalización debe realizarse a veces en varios proyectos a la vez ( cross-module customization).

Para tener un ciclo de vida del producto separado (mantenimiento, ramas de funciones) para el producto personalizado, presentamos el subárbol git. Tenemos un repositorio de git-subtree para todos los módulos personalizados. Nuestra personalización es 'git subtree push' de todos los días a todos los repositorios originales a las ramas de personalización.

Así evitamos administrar muchos repositorios y muchas braches. ¡git-subtree aumentó nuestra productividad varias veces!

ACTUALIZAR

Más detalles sobre la solución que se publicó en los comentarios:

Creamos un repositorio completamente nuevo. Luego agregamos cada proyecto que tenía una rama de cliente a ese nuevo repositorio como subárbol. Teníamos un trabajo de jenkins que hacía retroceder los cambios maestros de los repositorios originales a la rama del cliente con regularidad. Trabajamos solo con el "repositorio del cliente" usando el flujo típico de git con ramas de características y mantenimiento.

Nuestro repositorio de 'cliente' también tenía scripts de construcción que también adaptamos para este cliente en particular.

Sin embargo, existe un peligro de solución presentada.

A medida que nos alejábamos más y más del desarrollo principal del producto, la posible actualización para ese cliente en particular era cada vez más difícil. En nuestro caso, estuvo bien, ya que el estado del proyecto antes del subárbol ya estaba lejos de la ruta principal, por lo que el subárbol introduce al menos un orden y la posibilidad de introducir un flujo de git predeterminado.

Básicamente, Git-subtree son las alternativas para el enfoque de Git-submodule: hay muchos inconvenientes o, más bien, diría, debe tener mucho cuidado al usar git-submodules. por ejemplo, cuando tiene "un" repositorio y dentro de "uno", ha agregado otro repositorio llamado "dos" usando submódulos. Cosas que debes cuidar:

• Cuando cambia algo en "dos", necesita confirmar y presionar dentro de "dos", si está en el directorio de nivel superior (es decir, en "uno") sus cambios no se resaltarán.

• Cuando un usuario desconocido intenta clonar su "un" repositorio, después de clonar "uno", ese usuario necesita actualizar los submódulos para obtener los "dos" repositorios

Estos son algunos de los puntos y para una mejor comprensión te recomiendo que veas este video: https://www.youtube.com/watch?v=UQvXst5I41I

• Para superar estos problemas, se inventa el enfoque de subárbol. Para obtener los conceptos básicos sobre git-subtree, eche un vistazo a esto: https://www.youtube.com/watch?v=t3Qhon7burE

• Encuentro que el enfoque de subárbol es más confiable y práctico en comparación con los submódulos :) (Soy muy principiante para decir estas cosas)

¡Salud!

Para agregar a las respuestas anteriores, un inconveniente adicional de usar subárbol es el tamaño del repositorio en comparación con los submódulos.

No tengo ninguna métrica del mundo real, pero dado que cada vez que se realiza una inserción en un módulo, en todos los lugares donde se usa ese módulo se obtiene una copia del mismo cambio en el módulo principal (cuando se actualiza posteriormente en esos repositorios).

Entonces, si una base de código está muy modularizada, eso se sumará bastante rápido.

Sin embargo, dado que los precios del almacenamiento siempre están bajando, eso puede no ser un factor significativo.