Ramas Git con contenido completamente diferente

Question

Dado que Git tiene la capacidad de rastrear (y mantenerlo limpio) ramas con contenido completamente diferente, en el mismo repositorio, algunos proyectos (como Git) han comenzado a utilizar de eso

Git, por ejemplo, utiliza una rama para el código en sí, mientras mantiene su documentación en una rama separada. Mismo repositorio, solo diferentes ramas.

Podría ser solo yo, procedente de un fondo SVN, pero me resulta confuso tener "nada en común" en esas ramas. Ramas de desarrollo/estadificación/producción; aquellos que entiendo Ramas para características incompletas; seguro, yo también los estoy haciendo. Diablos, tenga su documentación con una rama por idioma. Pero no hay archivos en común?

¿Es esta característica justa (quizás infrautilizada y no utilizada) en Git, que todos deberían abrazar y acostumbrarse, o un mal uso posiblemente peligroso por ser perezoso de no diferenciar dos aspectos del mismo proyecto?

Answer 1

Yo personalmente no almacenaría contenido diferente en diferentes ramas; en el caso de los documentos y el código, simplemente crearía un myproject.git y un myproject-docs.git (y un submódulo los documentos en el código si fuera necesario para el proceso de compilación).

Por otro lado, nada malo sucederá si haces esto. Git no te dirá qué hacer, por lo que eres libre de tomar tu propia decisión sobre cómo quieres usarlo. Entonces, para responder a su pregunta, no es una característica decisiva, ni algo que le molestará si no tiene cuidado. Es solo cómo alguien elige usarlo.

Answer 2

El beneficio de hacer esto, es que es posible extraer solo la rama de documentos si eso es todo lo que le interesa. Como dijo jrockway, puede hacer esto usando otro repositorio y submodular si es necesario, pero con esta capacidad crea una rama 'desnuda', tienes la opción de no hacerlo.

Personalmente, todavía estoy en la cerca sobre esto. Entiendo por qué podría ser beneficioso, pero no estoy del todo convencido de que sea la mejor manera de hacerlo.

Answer 3

Es un poco raro cuando estás acostumbrado al modelo Subversion de presentar el árbol a los usuarios, pero una vez que te acostumbras al modelo es mucho menos confuso.

Un repositorio de git es solo un árbol de objetos que explican cómo transformar un directorio de un estado a otro. Esos objetos tienen un padre. Algunos objetos tienen dos (o más) padres; se fusiona. Algunos objetos no tienen padre; la confirmación inicial.

Según tengo entendido, internamente, el modelo de Subversion es similar, menos el concepto de origen de las fusiones. Esas son solo nuevas confirmaciones con un comando práctico (svn merge) para obtener un parche de las diferencias entre otras dos confirmaciones.

De hecho, uso esta característica bastante a menudo para administrar archivos de configuración que comenzaron desde el mismo directorio en hosts separados, como /etc/apache2. Es como decir: "este es el comienzo alternativo de estas cosas, pero ha sido abandonado". Me permite esconder el estado de algunos archivos antes de sobrescribirlos, pero sin tener que preocuparme de si combinan correctamente o si están relacionados con la rama principal.

En Subversion tendría que guardar esa copia de seguridad en algún lugar no relacionado (archivo zip en algún lugar) o en un subdirectorio en el repositorio. Además, en la subversión, si elimino cualquier referencia a esos archivos en la vista actual del árbol, es muy difícil encontrarlos de nuevo.

Answer 4

Diría que es más como una solución perezosa por el hecho de que Git actualmente no puede manejar tener múltiples proyectos almacenados en el mismo repositorio. Puedes hacerlo, pero no hay forma de tirar solo el que quieres.

Digo "perezoso", porque no habría sido demasiado horrible agregar la función cuando los desarrolladores de git la descubrieron como una necesidad (para almacenar documentos). Desde que usaron este raro hack de rama, su incentivo para arreglar el problema para todos los demás ha disminuido significativamente.

Answer 5

Creo que depende de lo que sea su proyecto.

Git es obviamente un proyecto de OSS de la comunidad por lo que tener los documentos en el (mismo) repositorio para que todos los tengan tiene sentido (para mí).

Por otro lado, no almacenaría los documentos para mis proyectos en el trabajo, ya que los editaría raramente, excepto en el tipo de ticket 'vamos a actualizar los documentos'. En el trabajo, no quiero que mis documentos se entremezclen con mi fuente, solo quiero la fuente (vista típica del programador que conozco).

Otros pueden quererlos todos juntos. Creo que solo necesita darse cuenta de lo que significa (recuerde que todos tienen una copia completa del repositorio) y elegir la mejor opción para su proyecto.

Answer 6

Git realiza un seguimiento de los cambios coordinados en los archivos (de texto) dentro de un proyecto, por lo que no sabe ni le importa si las ramas son compatibles o no. Tener ramas independientes en un repositorio de Git es similar a tener proyectos independientes en un repositorio de Subversion, que es una práctica común (debido a la sobrecarga de svn).

Como la estructura de datos de Git es muy diferente a la de los SVN, puedes hacer diferentes cosas con ellos. En SVN, una rama de características es algo inusual, y una rama de características que a menudo no se fusiona con el tronco podría ser un "mal olor", una señal de que el programador "se ha oscurecido" y está creando un código que nunca podrá ser integrado en el proyecto. En Git, una rama de características es un flujo de trabajo perfectamente seguro y sensato.

De modo que se pueden usar de diferentes maneras porque Git no es SVN aunque ambos tienen repositorios y ramas y confirmaciones, y cumplen la misma función general de control de fuente.

A medida que fui más experiencia de Git, lo que había sido raro sólo se convirtió en diferente. Luego sentí curiosidad acerca de qué podía hacer con esa herramienta diferente.