Mantenimiento de git repo que contiene otro repository git clonado

Estoy trabajando en un website usando Sharelatex (github) pero contiene otros repositorys que se usan para build el proyecto principal. Cloné el repository principal e hice la grunt install que se usa para download esos repositorys.

Pero el problema es que necesito cambiar el código tanto en el repository principal como en los descargados.

Dado que estos proyectos pueden get nuevas actualizaciones, también deseo fusionar esos cambios. También necesito mantener un repository, pero cuando cambio los cambios a Github, solo se muestran los cambios en el repository principal.

Encontré submodules en git pero dado que el proyecto principal no contiene ningún tipo de submodule, no puedo usarlo.

Por ejemplo:

Hay una web repository utilizada en el proyecto principal. Empiezo con algunas ediciones en los files en la web . Necesito estos cambios para reflejarlos en mi repository remoto para que otros puedan usarlos.

Ahora supongamos que después de un time una actualización importante para web repository web está disponible, ¿cómo debería usar eso?

grunt install en la grunt install en la línea de command para download este repository. No crea un submodule, pero clona ese repository en mi carpeta, que luego es ignorado por mi repository principal de git.

La pregunta puede parecer confusa, pero hice todo lo posible para explicar el problema.

En resumen:

  • No solo quiero realizar cambios tanto en el repository principal como en el otro que esté involucrado, sino también extraer y combinar esos otros repositorys cuando estén disponibles sus actualizaciones.

  • También necesito mantener un repository remoto de mi proyecto.

Estoy trabajando en un website usando Sharelatex (github) pero contiene otro repository que se usa para build el proyecto principal. […] Encontré submodules en git pero dado que el proyecto principal no contiene ningún tipo de submodule, no puedo usarlo.

En realidad, tienes un submodule. Eso es lo que es un repository nested, y (lo digo en serio) en cuanto a lo que necesitas entender para asimilar submodules, eso es todo lo que hay para los submodules. Para comprender los submodules, imagine que tiene un repository nested (si lo hace) y piense en los requisitos administrativos, lo que debe hacerse para soportar esa configuration en un dvcs.

Para empezar, cuando las personas clonan un proyecto que usa submodules de algún repos, todos ustedes han decidido que contiene commits publicados, ese clon obviamente tampoco obtendrá el repository del subproyecto (ciertamente no debería get su privacidad y Dios sabe qué … la versión de you-have-to-it). Por lo tanto, también deben get el repository del subproyecto desde alguno de sus repositorys publicados.

¿Cómo le dice a las personas que buscan sus commits dónde get los commit de subproyectos necesarios? Claramente, debe colocar una nota en algún lugar de un file comprometido que diga "aquí hay un repository que debería tener cualquier commit de $ subproject". git submodule se decidió por .gitmodules como el lugar convencional para almacenar notas como esta.

A continuación: bueno, ¿qué harán otros si la url que les entregas se desconecta? Es evidente que necesitarán usar otro repository. Por lo tanto, .gitmodules es solo sugerencias, el command del git submodule usa los valores actuales en su .git/config , que el git submodule init ha rellenado de los sugeridos en .gitmodules`.

Las operaciones del git submodule son todas así. Olvídalo. No se moleste en mirar el command hasta que necesite un poco de ayuda haciendo lo que ya ha hecho. Comience por el conocimiento, el simple hecho de que un submodule no es más que un repository nested, y el proyecto que lo usa no compromete nada más que un identificador de confirmación que se supone que está en algún lugar de ese repository nested. Eso es. Eso es todo lo que es un submodule.

Cuando se encuentre con tareas tediosas que debe realizar, busque un subcommand de git submodule que las haga por usted. No tiene que usar el subcommand. Todo lo que el subcommand está haciendo es automatizar tareas sencillas que de otro modo serían laboriosas. Es un set de herramientas para hacer lo que sea que necesites hacer, y no hay forma en la tierra que pueda o deba imponer una abstracción arbitraria y suficiente (<esa es la parte difícil) a todos en el mundo. Entonces es una bolsa de sorpresas.

Dicho esto, hay una importante git submodule update juego de security y el git submodule add para ti cuando hacen el git clone por ti. Los repositorys tienen convencionalmente el contenido repo real bajo el [sub] proyecto a nivel .git , pero si se echa un vistazo a una sucursal que no tiene ese subproyecto allí o si no necesita o quiere que ese subproyecto haya desaparecido, su .git también desaparecerá. no es lo que quieres cuando contiene no solo tu contenido desprotegido, sino todo el repository real. Entonces, cuando la git submodule update realiza su clonación inicial, .git directory .git del submodule a un pequeño rincón práctico (y arbitrario) en el repository del proyecto que lo contiene y reemplaza el directory .git que acaba de sacar del submodule con un file .git que contiene la ruta relativa al directory movido.

Para get ese levantamiento inicial en el repository que tiene actualmente, aléjelo de su repository actual, agréguelo y actualícelo desde donde sea que lo coloque, y luego repare las URL en .gitmodules ascendente en .gitmodules para comodidad de los demás.

Ahí. Ahora sabes absolutamente todo lo que necesitas saber para entender los submodules de Git y adquieres incrementalmente los detalles solo cuando los necesitas, para entender lo que el command del git submodule está haciendo por ti, y por qué no tienes que preocuparte por entender cada pequeña cosa en su página principal al frente. Al less eso pienso.

Si me he perdido algo importante, estaría muy contento de las correcciones (suaves o directas, realmente no me importa) en los comentarios.