¿Cuándo usar el subárbol git?

Te damos la bienvenida a proyecto online, en este lugar hallarás la respuesta a lo que buscabas.

Solución:

Debe tener cuidado de anotar explícitamente de qué está hablando cuando usa el término ‘subárbol’ en el contexto de git ya 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 administrar varios repositorios en uno. A diferencia de git-submodule, donde solo se almacenan metadatos en el repositorio raíz, en forma de .gitmodules, y debe administrar los repositorios externos por separado.

Más detalles

estrategia de fusión de subárboles 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 contrib y no está completamente integrado en git con 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  
'git subtree' add   -P   
'git subtree' pull  -P   
'git subtree' push  -P   
'git subtree' merge -P  
'git subtree' split -P  [OPTIONS] []

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é usar subárbol en lugar de submódulo?

Hay varias razones por las que puede encontrar subtree mejor usar:

• La gestión de un flujo de trabajo sencillo es sencilla.
• Versión anterior de git son compatibles (incluso antes v1.5.2).
• El código del subproyecto está disponible justo después del clone del super proyecto está hecho.
• subtree no requiere que los usuarios de su repositorio aprendan nada nuevo, pueden ignorar el hecho de que está utilizando subtree para gestionar las dependencias.
• subtree no agrega nuevos archivos de metadatos como submodules hace (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 upstream para los subproyectos es un poco más complicado.
• La responsabilidad de no mezclar códigos de superproyectos y subproyectos en las confirmaciones recae en usted.

Yo 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 con 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-subtree ya genera. Hasta que esto llegue a 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 al comparar 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 de git y la segmentación que puede ocurrir cuando una característica simplemente no da en el blanco.

Personalmente he creado un disgusto por git-submodule ya que me resulta más confuso de entender para los contribuyentes. Yo tambien prefiero mantener TODOS de mis dependencias administradas dentro de mis proyectos para facilitar un entorno fácilmente reproducible sin intentar 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 en su lugar 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 fusión de subárbol es asi requiere menos carga administrativa por parte de los usuarios de su repositorio. Eso funciona con mayores (antes de Git v1.5.2) clientela y tienes el código justo después de la clonación.

Sin embargo, si usa submódulos entonces tú puedes elegir 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 de 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 puede presionar 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 superrepositorios con muchos subrepositorios, el punto de elegir no clonar datos de algunos subrepositorios es una ventaja importante de los submódulos. Podemos limitar esto en función de los requisitos de trabajo y el uso del 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 principal producto 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.

Paralelamente, 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 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 enviaba cambios maestros a los repositorios originales a la rama del cliente con regularidad. Trabajamos solo con el “repositorio del cliente” utilizando el flujo típico de git con ramas de funciones 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 el orden y la posibilidad de introducir el flujo de git predeterminado.

---

---

Utiliza Nuestro Buscador