Proyectos dentro de proyectos usando Git

Question

¿Cómo configuro un proyecto Git para que contenga otros proyectos?

p.ej.Estoy trabajando en una aplicación de mapas en línea.Desarrollamos una herramienta GPS junto con un equipo en SF.Simultáneamente desarrollamos un script Python Geomapping junto con una preocupación diferente (que solo se preocupa por el geomapping).Nuestros propios archivos principales unen los dos y se basan en ellos para crear la aplicación que necesitamos.

Cada uno de los proyectos debe existir por sí mismo (las personas que tienen interés en el GPS solo tienen interés en el GPS), pero el proyecto "principal" que incluye a todos los demás debe ser accesible como un proyecto.

Pasé algún tiempo tratando de comprender los submódulos, pero parecen tener demasiada independencia para lo que se necesita.

Además, si es posible, sería bueno que cada uno de esos proyectos pudiera contener uno o dos guiones superpuestos.¿Podría un proyecto Git incluir un archivo que no sea parte de su 'raíz' de modo que cuando cualquiera de los equipos actualice este archivo, ambos puedan beneficiarse?

¿Es esto factible con Git?¿Con Mercurial?¿Importa el host (GitHub, Gitorious)?

Tengo la idea de usar Subversion para el 'principal', ignorando las carpetas .git y usando Git para los proyectos (ignorando las carpetas .svn), pero eso es solo un último recurso.

editar:

Para explicar por qué no quiero submódulos:

1. Cuando los usuarios descargan, el zip no incluye los submódulos (aquí & aquí).Lo mismo ocurre cuando incluso los colaboradores intentan configurar el proyecto.Esto es un obstáculo para el espectáculo.
2. Los submódulos están congelados: no seleccionan (fácilmente) la última versión del proyecto al que se apunta.
3. Otras razones como se señalan en las fantásticas respuestas a continuación y en este monólogo en NoPugs.

La fusión de subárboles (que Paul me presentó a continuación) no funcionará:Es difícil actualizar la fuente [de un subárbol] desde el proyecto en el que está fusionado, y esa fuente debe residir fuera de la carpeta 'raíz' del proyecto.Al ser una aplicación web, es vital que todas mis páginas se vinculen internamente a una carpeta dentro de ellas y que las pruebas y actualizaciones se realicen directamente dentro de esa carpeta.(Espero que esto sea claro y útil para otros).

Todavía se está estudiando la posibilidad de establecer "sucursales remotas", pero otras ideas siguen siendo bienvenidas.

Answer 1

No he encontrado que los submódulos sean particularmente útiles en los (pequeños) proyectos en los que he trabajado.Una vez que los haya configurado, trabajar en todo el proyecto requiere agregar parámetros adicionales a casi todos los comandos y la sintaxis no es completamente regular.Me imagino que si trabajara en proyectos más grandes con más submódulos, lo vería como una compensación más beneficiosa.

Hay dos posibilidades que mantienen los subproyectos como repositorios de git independientes que se extraen de su repositorio principal (de integración):

• Usando fusión de subárbol para llevar sus proyectos externos a subdirectorios separados en su repositorio principal que incluye sus archivos principales.Esto facilita la actualización del proyecto principal desde los proyectos externos, pero complica el envío de cambios a los proyectos externos.Considero que esto es una buena manera de incluir dependencias del proyecto, pero no funcionaría tan bien con archivos compartidos. Otra explicación sencilla (enlace arreglado).

• Configurar cada proyecto como una sucursal remota en su repositorio principal y fusionar cada uno de ellos en su master rama (integración) que también contiene sus archivos principales.Esto requiere cierta disciplina:si realiza algún cambio en los proyectos externos en su repositorio principal, debe realizarlos en la rama y luego fusionarlos en el maestro;y nunca querrás fusionarte con las ramas del proyecto.Esto facilita el envío de cambios a proyectos externos y es un uso perfectamente aceptable de ramas en Git.

  Sus scripts compartidos se pueden manejar como otra rama independiente en su directorio principal de la que sus socios externos pueden extraer y enviar como una rama remota.

Si intenta ejecutar SVN y Git en el mismo directorio, dificultará mucho el uso de bifurcaciones en cualquiera de los sistemas, porque SVN realiza bifurcaciones copiando directorios de archivos mientras Git rastrea los punteros.Ningún sistema verá automáticamente las sucursales que hagas en el otro.Creo que esa "solución" causa más problemas de los que vale la pena.

Answer 2

He usado git para coser juntos mi propio proyecto github alojado y una biblioteca de interfaz de usuario externo que quería utilizar. La biblioteca se encuentra alojado en un repositorio de subversión en sourceforge.

He utilizado git-submódulo y git-svn y ha funcionado razonablemente bien. Los inconvenientes fueron:

1. Con el fin de mantenerse al día con el repositorio biblioteca, que tenía que realizar una nueva comprometen a actualizar el submódulo git de hash "puntero". Esto se debe a submódulos git, a diferencia de svn: externos, están puestas a un particular, comprometerse ID. Esto puede no ser un inconveniente real, si en realidad se desea anclar una versión estable, que estaba trabajando con el código que fue WIP.

2. El tirón inicial de un repositorio git con submódulos requiere un paso adicional con "git submódulo init". Esto no es un problema para usted, pero para otras personas que utilizan el código que tendrá que recordar o se les diga que realizar este paso antes de compilar / ejecutar / probar su código.

3. Si utiliza la línea de comandos es fácil meter la pata con su repositorio git-add. Esto se debe a que escribe git add subm<tab> para completar a git add submodule, pero-completa automática a git add submodule/ - tenga en cuenta la barra final. Si se ejecuta el comando con la barra final, entonces se estremece las submódulo y añade todos sus archivos contenidos en su lugar. Esta es mitigado mediante el uso de git-gui, git add . o simplemente entrenarse para eliminar la barra (me ha pasado tantas veces que me entrené para eliminarlo)

4. Los submódulos compromete lío lata hasta git rebase -i. Me olvido de los detalles exactos, pero es especialmente malo si tiene un submódulo "sucio" y se ejecuta un rebase interactivo. Normalmente con un árbol sucia que no se puede rebasar, pero submódulos no son controlados. Tener varios submódulo se compromete en un grupo de rebase también causa problemas. La última de hash submódulo se ha comprometido a la primera selección en su lista, y esto es bastante difícil de corregir más adelante. Esto se puede solucionar con un flujo de trabajo más cuidadoso (es decir, decidir con cuidado al hacer su submódulo compromete ...) pero puede ser un PITA.

Los pasos para configurar esto eran algo a lo largo de las líneas de:

1. git svn clone https://project.svn.sourceforge.net/svnroot/project/project/trunk Ejecutar
2. empujón que como un proyecto Git "real" para, por ejemplo, github
3. Ahora en su propio repositorio git, ejecute git submodule init
4. git submodule add git://github.com/project subproject
5. Empuje eso también, a su propio repo este momento.

Es decir que, más o menos. Tendrá un nuevo directorio "subproyecto", que en su caso sería la biblioteca geomapping.

Cada vez que usted necesita para actualizar el código geomapping, tendría que ejecutar algo como:

cd subproject
git svn rebase
git svn push  # this updates the git mirror of the subproject
cd ..
git add subproject # careful with the trailing slash!
git commit -m "update subproject"
git push # this pushes the commit that updates the subproject

No he visto a muchos tutoriales en un flujo de trabajo git submódulo, así que espero que esto ayude a decidir.

Answer 3

git-submódulo podría ser lo que busca:

http://book.git-scm.com/5_submodules.html

http://git-scm.org/gitwiki/GitSubmoduleTutorial

Answer 4

Por lo poco que he leído sobre Externals , que parece ser un puerto de SVN 'externos' a GIT.

Esto resuelve algunos de los problemas con los submódulos GIT, incluyendo la actualización a la versión más reciente de forma automática.

Si bien no tengo experiencia con las referencias externas o SVN con este proyecto, que podría ser una solución mejor para unos que cualquiera de los otros escritos.

Por otra parte, el software siguiente (parece que puede ser utilizado con GitHub). Puede ser otra manera para algunos a la piel del gato: Braid ( página Softpedia )

Answer 5

Depende de qué tipo de proyecto que está trabajando, y qué herramientas, en su caso, la necesidad de interactuar con el SMC. Rieles, por ejemplo, a menudo utiliza para desplegar Capistrano, y Capistrano hace ciertas suposiciones acerca de lo que su estructura de directorios se verá como en relación con la raíz de su repositorio. En este caso, si tiene varias aplicaciones carriles relacionados entre sí, es necesario usar submódulos. Cada aplicación tiene su propio repositorio, y entonces usted tiene un repositorio más grande que maneja cada uno de los repositorios independientes como submódulos.

Incluso si usted no tiene las herramientas que hacen que este tipo de supuestos, buen diseño del repositorio requiere que se rompe un poco las cosas, si hay la más mínima posibilidad de que algún día podría querer usar una subsección de un proyecto más amplio de forma independiente o reutilizar alguna gran franja de código dentro de algún proyecto independiente.

Extracción algunos subsección de un repositorio como su propia entidad separada, manteniendo el historial de versiones es difícil en Git, y lo que es una buena idea para planificar el futuro.

En cuanto a su pregunta específica, honestamente, yo lo llamaría un perfecto ejemplo de que un par de submódulos serían ideales. En relación con el intercambio de secuencias de comandos, si por alguna razón que en realidad es un tema que resulta problemático, siempre se puede utilizar un enlace simbólico.