remove - git tag best practices

Cuándo usar el subárbol de git? (5)

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

He leído que se usa para la separación de repositorios . Pero ¿por qué no crearía simplemente dos repositorios independientes en lugar de unir dos sin relación en uno?

Este tutorial de GitHub explica cómo realizar fusiones de subtítulos Git .

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

Básicamente Git-subárbol son las alternativas para el enfoque Git-submódulo: hay muchos inconvenientes, o más bien diría yo, debes ser muy cuidadoso al usar git-submódulos. por ejemplo, cuando tiene "un" repo y dentro de "uno" ha agregado otro repo llamado "dos" usando submódulos. Cosas que debes cuidar:

Cuando cambias algo en "dos", necesitas comprometer e insertar dentro de "dos", si estás en el directorio de nivel superior (es decir, en "uno") tus cambios no se resaltarán.
Cuando un usuario desconocido intenta clonar el repositorio "uno", después de clonar "uno" ese usuario necesita actualizar los submódulos para obtener el repositorio "dos"

Estos son algunos de los puntos y para una mejor comprensión, le recomendaría que vea este video: https://www.youtube.com/watch?v=UQvXst5I41I&t=576s

Para superar tales problemas, se inventa el enfoque del subárbol. Para obtener los conceptos básicos sobre git-subárbol, tenga una opinión sobre esto: https://www.youtube.com/watch?v=t3Qhon7burE&t=772s
Encuentro que el enfoque de subárbol es más confiable y práctico que los submódulos :) (soy muy principiante para decir estas cosas)

¡Aclamaciones!

Debe tener cuidado de observar explícitamente de lo que está hablando cuando use el término ''subárbol'' en el contexto de git ya que en realidad hay dos temas separados pero relacionados aquí:

git-subtree y git subárbol fusión estrategia .

El TL; DR

Ambos conceptos relacionados con el subárbol le permiten administrar múltiples 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 combinación de subárbol de git es básicamente el método más manual que utiliza los comandos a los que se hace referencia.

git-subárbol es un script de shell contenedor para facilitar una sintaxis más natural. Esto en realidad todavía es parte de contrib y no está completamente integrado en git con las páginas de manual habituales. La git-subtree 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>]

He encontrado una cantidad bastante buena de recursos sobre el tema de 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:

Gran parte de lo que está buscando se puede encontrar en este blog de Atlassian por Nicola Paolucci en la sección pertinente a continuación:

¿Por qué usar subárbol en lugar de submódulo?
Hay varias razones por las que puede encontrar un subtree mejor para usar:
La gestión de un flujo de trabajo simple es fácil.
La versión anterior de git es compatible (incluso antes de v1.5.2 ).
El código del subproyecto está disponible justo después de que se clone el clone del superproyecto.
subtree no requiere que los usuarios de su repositorio aprendan nada nuevo, pueden ignorar el hecho de que está utilizando un subtree para administrar dependencias.
subtree no agrega nuevos archivos de metadatos como los submodules (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 ).
El código de contribución de vuelta para los subproyectos es un poco más complicado.
La responsabilidad de no mezclar el código de súper y subproyecto en commits recae en ti.

Estoy de acuerdo con mucho de esto también. Yo recomendaría revisar el artículo ya que pasa por un uso común.

Puede haber notado que también ha escrito un seguimiento here donde menciona un detalle importante que queda con este enfoque ...

git-subtree no incluye el control remoto!

Esta miopía se debe probablemente al hecho de que las personas a menudo agregan un control remoto de forma manual 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, podrías hacer algo similar modificando el mensaje de confirmación o almacenándolo en otra confirmación.

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

Extras

Pensamientos finales

Este tema muestra tanto el poder de git como la segmentación que puede ocurrir cuando una característica simplemente falla la marca.

Personalmente he creado una aversión por git-submodule de git-submodule porque 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 repositorios múltiples. git-submodule , sin embargo, es mucho más conocido actualmente, por lo que obviamente es bueno tenerlo en cuenta y, dependiendo de su público, puede influir en su decisión.

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 cualquier lugar que se use ese módulo 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á altamente modularizada, se agregará bastante rápido.

Sin embargo, dado que los precios de almacenamiento siempre bajan, puede que no sea un factor significativo.

Primero de: creo que su pregunta tiende a obtener respuestas fuertemente dogmáticas y puede considerarse fuera de tema aquí. Sin embargo, no me gusta esa política de SO y me alejaría un poco del tema, así que me gustaría responder y esperar que otros también lo hagan.

En el tutorial de GitHub que señaló que hay un enlace a Cómo utilizar la estrategia de combinación de subárbol que ofrece un punto de vista sobre las ventajas / desventajas:

Comparación de fusión de subárbol con submódulos
El beneficio de usar la combinación de subárbol es que requiere menos carga administrativa de los usuarios de su repositorio. Funciona con clientes más antiguos (antes Git v1.5.2) y usted tiene el código justo después del clon.
Sin embargo, si usa submódulos , puede optar por no transferir los objetos del submódulo . Esto puede ser un problema con la fusión del subárbol.
Además, en caso de que realice cambios en el otro proyecto, es más fácil enviar cambios si solo utiliza submódulos.

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

A menudo trabajo con gente (= committers) que no son usuarios regulares 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, fusión, ramas y luego mezclar todo en un flujo de trabajo. Tirando de la corriente ascendente y empujando aguas arriba es un proceso de dos etapas. Como las ramas son difíciles de entender para ellos, todo esto es inútil.

Con los submódulos sigue siendo 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 hacer tus tira y tira como de costumbre.

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

Para superrepos grandes con muchos sub-repos, el punto de elegir no clonar datos de algunos sub-repos es una ventaja importante de los sub-mó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 repos requieren diferentes controles de acceso, prohibiendo efectivamente algunos usuarios de algunos sub-repos, me pregunto si eso es más fácil de lograr con el enfoque de submódulo.

Personalmente, no estoy seguro de qué usarme. Entonces comparto tu confusión: o]

Un caso de uso real que tenemos donde el subárbol de git 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 está compuesto con todos los módulos de versiones concretas.

Paralelamente, la versión concreta del producto completo 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 por separado (mantenimiento, ramas de características) para productos personalizados, presentamos el subárbol de git. Tenemos un repositorio git-subárbol para todos los módulos personalizados. Nuestra personalización es cada día ''git subtree push'' de vuelta a todos los repositorios originales a las ramas de personalización.

Así evitamos gestionar muchos repos y muchos braches. git-subárbol aumentó nuestra productividad varias veces!