traemos tag repositorio remoto que los cómo crear conectar con cambios git version-control git-submodules

tag - Proyectos dentro de proyectos usando Git



que es un repositorio git (5)

Depende del tipo de proyecto en el que esté trabajando y qué herramientas, si las hay, necesitan interactuar con su SCM. Rails, por ejemplo, a menudo usa Capistrano para desplegar, y Capistrano hace ciertas suposiciones acerca de cómo se verá la estructura de su directorio en relación con la raíz de su repositorio. En este caso, si tiene varias aplicaciones de rieles interrelacionados, debe utilizar submódulos. Cada aplicación tiene su propio repositorio, y luego usted tiene un repositorio más grande que administra cada uno de los repositorios independientes como submódulos.

Incluso si no tiene herramientas que hagan este tipo de suposiciones, un buen diseño de repositorio requiere que divida un poco las cosas si existe la mínima posibilidad de que algún día quiera usar una subsección de un proyecto más grande de forma independiente, o reutilizar Alguna gran franja de código dentro de algún proyecto independiente.

Extraer una subsección de un repositorio como su propia entidad separada mientras se mantiene el historial de versiones es difícil en git, por lo que es una buena idea planificar con anticipación.

En cuanto a su pregunta específica, honestamente, llamaría a eso un ejemplo perfecto de donde un par de submódulos serían ideales. Con respecto a compartir scripts, si por alguna razón ese es realmente un problema que resulta problemático, siempre puedes usar un enlace simbólico.

¿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. Al mismo tiempo, desarrollamos un script de Python Geomapping junto con una preocupación diferente (que solo se preocupa por el geomapping). Nuestros propios archivos centrales unen los dos y se basan en ellos para 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.

He pasado algún tiempo tratando de entender los submódulos, pero parecen tener demasiada independencia para lo que se necesita.

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

¿Es esto posible con Git? ¿Con Mercurial? ¿Importa el anfitrión (GitHub, Gitorious)?

Tengo la idea de usar Subversion para el ''padre'', 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 ( here y here ). Lo mismo ocurre cuando incluso los colaboradores intentan configurar el proyecto. Este es un show stopper.
  2. Los submódulos están congelados: no recogen (fácilmente) la última versión del proyecto al que se apunta.
  3. Otras razones como se señala en las fantásticas respuestas a continuación y en este monólogo de NoPugs .

La fusión de subárbol (presentada por Paul, a continuación) no servirá: es difícil actualizar la fuente [de un subárbol] desde el proyecto en el que se fusiona, y esa fuente debe residir fuera de la carpeta ''raíz'' de el 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).

Sigo estudiando la creación de ''sucursales remotas'' pero otras ideas son bienvenidas.

He utilizado git para unir mi propio proyecto alojado en github y una biblioteca de interfaz de usuario externa que quería usar. La biblioteca está alojada en un repositorio de subversion en sourceforge.

Usé git-submodule y git-svn y funcionó razonablemente bien. Las desventajas fueron:

  1. Para mantenerme actualizado con el repositorio de la biblioteca, tuve que realizar una nueva confirmación para actualizar el submódulo de "puntero" de hash de git. Esto se debe a que los submódulos de git, a diferencia de svn: externals, están anclados a un ID de confirmación en particular. Es posible que esto no sea un inconveniente real si realmente desea fijar una versión estable, estaba trabajando con un código que era WIP.

  2. La extracción inicial de un repositorio git con submódulos requiere un paso adicional con "git submodule init". Esto no es un problema para usted, pero para otras personas que usen su código, deberán recordarlo o pedirle que realice este paso antes de compilar / ejecutar / probar su código.

  3. Si usa la línea de comandos, es fácil arruinar su repositorio con git-add. Esto se debe a que escribe git add subm<tab> para completar a git add submodule , pero se completa automáticamente para git add submodule/ - note la barra diagonal final. Si ejecuta el comando con la barra inclinada al final, entonces bombardea el submódulo y agrega todos los archivos que contiene. Esto se mitiga utilizando git-gui, git add . o simplemente entrenándote para eliminar la barra (me sucedió suficientes veces que me entrené para eliminarlo)

  4. Los submodulos comprometidos pueden desordenar git rebase -i. Olvidé los detalles exactos, pero es especialmente malo si tienes un submódulo "sucio" y ejecutas un rebase interactivo. Normalmente, con un árbol sucio no se puede rebase, pero los submódulos no se verifican. Tener varios compromisos de submódulos en un grupo de rebase también causa problemas. El último hash de submódulo se compromete con la primera selección de tu lista, y esto es bastante difícil de arreglar más tarde. Esto puede solucionarse con un flujo de trabajo más cuidadoso (es decir, decidir con cuidado cuándo realizar sus confirmaciones de submódulos ...) pero puede ser un PITA.

Los pasos para configurar esto fueron los siguientes:

  1. Ejecute git svn clone https://project.svn.sourceforge.net/svnroot/project/project/trunk
  2. Empuje eso como un proyecto git "real" a, por ejemplo, github
  3. Ahora, en tu propio repositorio git, ejecuta git submodule init
  4. git submodule add git://github.com/project subproject
  5. Empuje eso también, a su propio repo esta vez.

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

Cada vez que necesite actualizar el código de geomapping, 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 muchos tutoriales en un flujo de trabajo de submódulos de git, así que espero que esto te ayude a decidir.

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 obtiene de su repositorio principal (integración):

  • Use la combinació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 es complicado enviar los cambios a los proyectos externos. Pienso en esto como una buena manera de incluir dependencias de proyectos, pero no funcionaría tan bien con archivos compartidos. Otra explicación simple (enlace fijo) .

  • Configure cada proyecto como una rama remota en su repositorio principal y fusione cada uno de ellos en su rama master (integración) que también contiene sus archivos principales. Esto requiere algo de disciplina: si realiza cambios en los proyectos externos en su repositorio principal, estos deben realizarse en la sucursal y luego fusionarse en el maestro; y nunca querrás unirte a las ramas del proyecto. Esto facilita el envío de cambios a los proyectos externos y es un uso perfectamente aceptable de las sucursales en Git.

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

Si intenta ejecutar SVN y Git en el mismo directorio, hace que sea muy difícil usar la bifurcación en cualquiera de los sistemas, ya que SVN realiza la bifurcación al copiar directorios de archivos mientras que Git rastrea los punteros. Ningún sistema vería automáticamente las ramas que haces en el otro. Creo que la ''solución'' es más problema de lo que vale.

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

Esto resuelve algunos de los problemas con los submódulos GIT, incluida la actualización automática a la última versión.

Si bien no tengo experiencia con SVN externos o con este proyecto, podría ser una mejor solución para algunos que cualquiera de los otros publicados.

Alternativamente, el siguiente software (parece que puede usarse con GitHub). Puede ser otra forma para que algunos despellejen al gato: Braid ( página de Softpedia )