Git repo inside repo

Question

Quiero clonar https://github.com/getyouridx/pychargify en mi proyecto django, y necesitaré extraer actualizaciones de vez en cuando.

Solo para aclarar, ¿podría simplemente escribir un gitignore desde el directorio raíz del proyecto django, p. .gitignore: pychargify/.git o hay otras trampas que debería tener en cuenta?

Answer 1

tener uno repositorio git "dentro de" otra, un vistazo a los submódulos git: http://git-scm.com/book/en/Git-Tools-Submodules

Al hacer pychargify un submódulo de su proyecto Django, las revisiones específicas de su proyecto de Django pueden ser asociados con revisiones específicas de su proyecto pychargify . Eso puede ser realmente útil.

No estoy seguro de cuáles son los peligros del enfoque que describes, pero no pasa la prueba de olor para mí. Yo recomendaría usar la característica Git (submódulos) que está diseñada específicamente para este tipo de cosas.

Answer 2

Git tiene una función para tener un repositorio dentro de otro: submodules.

git submodule add https://github.com/getyouridx/pychargify.git 

Asegúrese de leer toda la documentación sobre submódulos, ya que como algunas peculiaridades que participan con su uso, y los pasos adicionales que se deben tomar cuando se hace una copia nueva de su propio repositorio para inicializar los submódulos.

También tenga en cuenta que todos los comandos del submódulo se deben realizar en el directorio raíz de su repositorio.

Answer 3

Git lo ignora automáticamente y ni siquiera le permite agregar ningún archivo/carpeta llamada .git. Entonces puede agregar un repositorio dentro de su repositorio y trabajar en él. Sin embargo, es posible que deba ignorar la carpeta repo interna pychargify.

Los submódulos son necesarios cuando quiere compartir el repositorio con otros que lo clonarán, etc. Si solo está buscando clonar el repositorio interno y trabajar en su repositorio local sin nadie más involucrado o no quiere para tener el repositorio en otro lugar también, realmente no necesitas submódulos.

Answer 4

subárboles Git

Git submodules es una forma común, ganando mucho terreno desde introdujo, con el fin de hacer frente a la situación en la que uno puede desear agregar un proyecto (repo) dentro de otro proyecto (repo), como las otras respuestas han descrito correctamente.

Sin embargo, podría argumentarse que la forma de los submódulos no es la única y ocasionalmente inadecuada, dependiendo de los flujos de trabajo establecidos, por varias razones que no voy a analizar y que se mencionan brevemente en varias páginas como this y this. El más importante es sin duda esto:

Cuando Git entra en modo de resolución de conflictos, que todavía no actualiza los punteros submódulo - lo que significa que cuando se comprometa la fusión después de la resolución de conflictos, se encuentra con el mismo problema. ..: si olvidó ejecutar la actualización del submódulo git, acaba de revertir cualquier commit de submódulo que la rama en la que se fusionó podría haber realizado.

Por supuesto, en un flujo de trabajo perfecto esto nunca sucedería.

Otra razón importante es que el popular PyCharm IDE (cuando esto está escrito, hay un muy old issue para eso) y posiblemente otros también no implementan completamente los submódulos de git y el codificador perderá entre otros la ingeniosa funcionalidad del IDE que muestra todas las líneas modificadas en el submódulo.

Por lo tanto, una forma alternativa de resolver este problema es usar subárboles. Tenga en cuenta que los subárboles y subtree merging no es exactamente lo mismo, pero esto es otra cuestión. El excelente Progit book en su segunda edición cubre brevemente este último, pero no una referencia única para el primero.

Así, en un ejemplo práctico, con el fin de hacer frente a la situación bajo interés, por no suponer un subproject para ser consumido en un project:

$ git remote add subproject_remote (url) 
# subproject_remote is the new branch name and (url) where to get it from, it could be a path to a local git repo 

$ git subtree add —-prefix=subproject/ subproject_remote master 
# the prefix is the name of the directory to place the subproject 

$ git commit -am "Added subproject" 
# possibly commit this along with any changes 

Si los cambios de subproyectos, a tirar de ellos en project:

git subtree pull —prefix=subproject subproject_remote master 

... o lo contrario (si se realizan cambios en el interior de la subprojectproject):

git subtree push —prefix=subproject subproject_remote new_branch 

Un tutorial analítico pero bastante ruidoso en este link.

Esta funcionalidad también tiene algunos inconvenientes, por ejemplo, mucha gente considera que el flujo de trabajo es engorroso y más complicado, pero una vez más esto depende de los flujos de trabajo establecidos.

Answer 5

Añadir una carpeta que contenga un proyecto git dentro de otro proyecto git funciona como es de esperar: no hay interacción directa entre ellos y puede realizar cambios de forma independiente trabajando en un directorio u otro. Puede hacer que el proyecto "principal" ignore por completo la carpeta interna o puede confirmar los archivos seleccionados de la carpeta secundaria como si fueran parte del proyecto principal.

Si hace esto último, cuando modifique un archivo se verá como modificado por ambos proyectos de git y podrá gestionar esos cambios de forma independiente (confirmar los cambios) simplemente trabajando en un directorio u otro.

Supongo que está utilizando las herramientas de línea de comandos aquí, aunque creo que XCode 7 puede entender la situación y mostrar anotaciones de cambio en los archivos mientras los archivos se vean modificados por uno o ambos repositorios git .

Creo que el procedimiento anterior es más simple que tratar con submódulos, pero otros han comentado sobre cómo usarlos, por lo que es posible que desee compararlos.