¿Podría usar GIT en una situación en la que cada file es esencialmente su propio repository?

NOTA: Aunque (a partir de las discusiones que ya se han llevado a cabo) parece que GIT no es una buena opción para este caso de uso, he abierto esta pregunta para get una respuesta más definitiva, con suerte de alguien que tiene mucha experiencia con GIT. La pregunta original está abajo.

Tengo una situación en la que tengo una gran colección de files que son independientes. Por independiente quiero decir que cada file no depende de la presencia, ausencia o estado particular de los files que lo rodean. Una buena analogía sería un directory de imágenes, donde nuestro flujo de trabajo permite que cada image sea creada, editada y eliminada de manera independiente, y el trabajo realizado en una image no tiene relación con las otras imágenes en el directory.

Tenga en count que esta independencia no es solo incidental, sino que es fundamental para nuestro flujo de trabajo.

Cada uno de estos files se beneficiaría de un GIT como flujo de trabajo. Sería bueno poder rastrear los cambios en cada file, hacer que las personas trabajen en cada file en sucursales independientes y luego fusionar sus cambios cuando terminen (así que, por el bien de nuestra analogía, imagine que estas son imágenes SVG, donde podría tener un artista dibujando la image y un traductor que traduce el contenido del text) y acceder a los files de otros proyectos que usan GIT.

Según mi experiencia, GIT es excelente cuando tienes una colección de files que están todos en un estado particular. Por ejemplo, cuando se compromete un repository de GIT después de alcanzar el estado de "Production Release 1.2", cada file comparte el estado de "Production Release 1.2" en esa confirmación.

Pero no estoy seguro de cómo aplicar el flujo de trabajo de GIT, o si es práctico hacerlo, cuando cada file no comparte y no puede compartir el estado de los files que lo rodean. Puede colocar cada file en su propio repository GIT, pero eso no parece práctico.

Entonces, mis preguntas son:

  1. ¿Es correcta mi printing de que GIT solo funciona en una colección de files relacionados?
  2. De no ser así, ¿cuál sería el process para usar la funcionalidad clon / sucursal / fusión de GIT file por file?

ACTUALIZAR

En respuesta a iberbeu: no es que vea versiones como XY, es que veo que GIT se compromete asumiendo que todos los files en un repos tienen la misma versión o punto de confirmación (como defina una versión). En ese caso, los files en un repository GIT no son totalmente independientes.

El problema aquí es cuando toma un solo repository con todos los files independientes, lo clona en su propio repository local y comienza a trabajar en una sucursal. En este punto, se supone que todos los files pertenecen a la twig, aunque desde el punto de vista del flujo de trabajo que tenemos, solo está trabajando en un único file. Sin embargo, ahora todos estos files independientes están "listos para el viaje", asumiendo el historial de revisión asociado con el único file que realmente desea editar.

Entonces Joe podría crear una twig de una llamada de repo "Joe Working on Image 1". Su sucursal tiene la Imagen 1, en la que quiere trabajar, y otras 10.000 imágenes que no le interesan.

Jane podría crear una twig del mismo repository llamada "Jane trabajando en Image 987". Su sucursal tiene Image 987, en la que quiere trabajar, y otras 10,000 imágenes que no le interesan.

Esto está bien, siempre que Joe y Jane no tengan la tentación de comenzar a editar algunas otras imágenes en su twig. Pero si lo hicieron, perdemos el model conceptual de cada image que se edita como una entidad independiente, y se edita de forma aislada de las otras imágenes.

Entonces, si Joe editó la Imagen 2 en la twig donde debería haber estado editando solo la Imagen 1, y fusionó esos cambios nuevamente en el repository, ahora el historial de revisión explícito de la Imagen 2 se editó junto con la Imagen 1. Pero las Imágenes 1 y 2 deberían ser completamente independiente. No debería haber noción de Imagen 2 ya que fue editada junto a la Imagen 1.

Entonces este es el quid de la cuestión. ¿GIT respalda la noción de los files que controla como entidades aisladas cuyas revisiones no se correlacionan con ningún otro file? ¿O solo se puede lograr con repositorys git individuales para cada file?

ACTUALIZACIÓN 2

Parece que un submodule podría ser un reemploop para tener miles de repositorys GIT.

Como han dicho otros, git se puede usar para muchos repositorys de file único, aunque es (como usted señala) más útil para administrar un set de files.

Para administrar miles de repositorys de un solo file, la herramienta Gitslave puede ser útil. Esta herramienta permite crear muchos repositorys y administrarlos en uno. Una vez que tenga sus repositorys, puede, por supuesto, trabajar con cada uno de forma independiente, pero Gitslave hace que sea más fácil realizar operaciones grupales sobre ellos como empujar / tirar o comprometerse.

Esto es en mi humilde opinión una mejor solución que muchos submodules de Git, ya que los submodules pueden ser difíciles de manejar.

Desde la página de inicio:

Gitslave crea un grupo de repositorys relacionados, un repository de superproyectos y un número de repositorys esclavos, todos los cuales se desarrollan concurrentemente en los que todas las operaciones de git deberían funcionar normalmente; así que cuando se bifurca, cada repository en el proyecto se ramifica a su vez. Del mismo modo, cuando compromete, empuja, tira, combina, label, pago, estado, logging, etc. cada command git se ejecutará en el superproyecto y en todos los repositorys esclavos sucesivamente.

[…]

Gitslave no se hace cargo de su repository. Puede seguir utilizando los commands de git henetworkingados tanto dentro de un repository clonado de gits como fuera de un repository privado clonado por git.

Realmente no veo el problema. Creo que ve un repository como una forma de versionar su código (files en este caso). Aunque eso es correcto, la idea puede llevarte a un error porque no significa que comprometes siempre la versión en el formatting XY

Lo que quiero decir es que puede ver un repository como una línea de time en la que tiene diferentes estados del contenido de una carpeta. No importa si los files están relacionados entre sí o no.

Con Git siempre puedes get una versión anterior de un solo file, no necesitas volver a un estado completo del repository.

Entonces, no hay ninguna diferencia, en su caso, entre un repository con varios files independientes y varios repositorys con un file cada uno. En realidad, hay una gran diferencia, la primera opción es asequible y la segunda es imposible de manejar.

En realidad, un proyecto normal tiene files que son totalmente independientes, pero todos pertenecen al mismo repository.

Git no tiene problemas para crear un repository para un solo file.

Si no desea crear un repository por file y no necesita ver todos esos files en su directory al mismo time, puede comenzar con un repository vacío y crear una twig para cada uno de esos files. Si no realiza ninguna fusión entre estas sucursales independientes, se mantendrá independiente. Aún podrá crear nuevas twigs fuera de la twig de un file específico y fusionar los cambios.

Uso CVS donde cada file es independiente de todos los demás en el repository.

Como extra, esto le permite ejecutar "cvs update" en algunos files, mientras deja a otros en paz.

Esto es útil cuando puedo haber modificado los files en el espacio de trabajo local, y también he comprobado los cambios desde otro espacio de trabajo. A menudo quiero sincronizar con los files que han cambiado solo en el repository, sin molestarme en tratar con los files que podrían necesitar fusionarse.

Esto dio lugar a un script que llamo cvs-update-safe que actualiza de forma rápida y sin problemas todos los files que son seguros para actualizar, mientras deja otros files solos para ser tratados manualmente más tarde.

No soy un gran admirador de CVS para nada de complejidad (prefiero git), pero tiene las ventajas de ser omnipresente, y me permite la opción de actualizar solo partes de un repository.

#!/usr/bin/python # $Id: cvs-update-safe,v 1.1 2007-11-02 19:47:02 falk Exp $ usage = """Like cvs update, but only updates files which will update cleanly. Usage: cvs-update-safe [files...] """ import sys import os import string import commands def main(): cmd = 'cvs -n update ' + string.join(sys.argv[1:], ' ') output = commands.getoutput(cmd).split('\n') olist = [] for line in output: line = line.split() if line[0] is 'U' and len(line) is 2: olist.append(line[1]) if olist: cmd = 'cvs update ' + string.join(olist, ' ') os.system(cmd) else: print 'Nothing to update' if __name__ == "__main__": sys.exit(main()) 

Puede usar un repository único y usar ganchos git para aplicar una granularidad de uno.

Un enlace precompromiso del lado del cliente aseguraría que una confirmación tuviera cambios en un solo file, y opcionalmente un gancho prepare-commit-msg prefija automáticamente el post de confirmación con el nombre del file.

Un gancho de pre-recepción del lado del server podría hacer cumplir lo anterior.

Todavía tendrías el problema del ruido de la señal de tener eventualmente un gran número de twigs independientes.

Creo que comenzaste esta discusión con una pregunta incorrecta.

El párrafo:

Cada uno de estos files […] y acceder a los files de otros proyectos que usan GIT.

(especialmente: acceda a los files de otros proyectos que usan GIT ) sugiere que todo lo que desea es una colección de repositorys a la que se accede desde otro proyecto.

Creo que la mejor solución es usar submodules.

Establezca un nuevo repository para cada uno de sus "files". Los llamaré "repository de un solo file".

En el proyecto que usa repositorys "one-file-repo", definen submodules.

El hecho de que los repositorys de "un file de repository" contengan un solo file no es importante.

El trabajo dentro de "repository de un solo file" está aislado, pero no necesariamente restringido a un único file.

Con un único repository, puede optar por solo confirmar un file a la vez, dando a cada file un post de confirmación diferente. Pero cuando clonas el repository, aún terminarás descargando todo el repository. Git es un sistema de control de versiones distribuidas , y este es un efecto secundario de eso.

Puede asignar a cada file su propio repository git e importarlos a otros repositorys git mediante el submodule. Puedo ver que es un poco difícil de manejar, pero las ventajas de usar un dvcs es que siempre tienes el historial de tu repository en tu computadora.

Otra cosa a considerar es que podrías estar usando la herramienta incorrecta para el trabajo. SVN es un sistema de control de versiones centralizado que le permite consultar files individuales (extracción dispersa) en lugar de clonar todo el repository. Puede usar herramientas como git-svn para enlazar a sus repositorys Git existentes.

De cualquier manera, no es un process divertido. Tener un repository de git separado por file puede ser el less complicado.