tag - Git ramas con contenido completamente diferente
git push (6)
Creo que depende de cuál es tu proyecto.
Git es obviamente un proyecto de OSS de la comunidad, así 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 ''vamos a actualizar los documentos'' del ticket. 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 a 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.
Dado que Git tiene la capacidad de hacer un seguimiento (y mantenerlo limpio) de las ramas con contenido completamente diferente el uno del otro, en el mismo repositorio, algunos proyectos (como Git) han comenzado a hacer uso de él.
Git, por ejemplo, usa 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, proveniente de un pasado 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 una característica (tal vez una subutilizada o infrautilizada) en Git, que todos deben abrazar y acostumbrarse, o un mal uso posiblemente peligroso por parte de alguien que es perezoso de no diferenciar lo suficiente dos aspectos del mismo proyecto?
Diría que es más como una solución perezosa por el hecho de que Git no puede manejar varios proyectos almacenados en el mismo repositorio. Puedes hacerlo, pero no hay forma de tirar solo el que quieres.
Digo "flojo", porque no habría sido demasiado difícil agregar la función cuando los desarrolladores de git la descubrieron (para guardar documentos). Desde que usaron este raro hack de rama, su incentivo para arreglar el problema para todos los demás ha disminuido significativamente.
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 de crear un ''desnudo'' ''rama, 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.
Es un poco extraño cuando estás acostumbrado al modelo de Subversion de presentar el árbol a los usuarios, pero una vez que te acostumbras al modelo es mucho menos confuso.
Un repositorio git es solo un árbol de objetos que explica 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 muy 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.
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 o no pueden fusionarse. 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).
Debido a que la estructura de datos de Git es muy diferente a la de SVN, puedes hacer cosas diferentes 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.
Por lo tanto, se pueden usar de diferentes maneras porque Git no es SVN aunque ambos tengan repositorios, ramas y confirmaciones, y cumplan la misma función general de control de origen.
A medida que adquirí más experiencia con Git, lo que había sido extraño simplemente se volvió diferente . Entonces sentí curiosidad acerca de qué podía hacer con esa herramienta diferente.
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.