Tengo problemas para descubrir cómo cambiar mi mentalidad a git y me he encontrado con el siguiente problema. Tengo la situación en la que tenemos un motor compartido y múltiples proyectos que usan el motor. Los equipos de desarrollo interno y los equipos de terceros pueden estar trabajando en proyectos que usan el motor compartido, y desean usar HEAD del motor compartido tanto como sea posible durante el desarrollo, hasta solo unas pocas semanas antes del envío, donde se etiquetará el motor compartido y ramificado, y el proyecto utilizará esa rama. Los equipos de proyecto generalmente solo trabajan en un proyecto a la vez, pero pueden realizar cambios en el motor compartido durante la depuración o para agregar características. Cuando confirman esos cambios, nuestro sistema de compilación se ejecuta para encontrar cualquier problema que puedan haber introducido con la confirmación.

Creo que quiero usar este mismo modelo con un nuevo proyecto / nueva empresa. En svn, la estructura era algo como esto: shared_engine

project_in_dev-+
               +- svn:external shared_engine:head
project_about_to_ship-+
                      +-svn:external shared_engine_rev1_branch

Esto funcionó muy bien:

Los desarrolladores de proyectos podrían hacer un comando para verificar todas las dependencias que necesitaríanLos desarrolladores de proyectos podrían hacer el trabajo del motor y comprometerse con el motor compartido fácilmentePodríamos acelerar o cambiar fácilmente el motor compartido que el proyecto estaba usando con externos y revisionesLas actualizaciones del motor fueron fáciles de obtener con su "actualización diaria desde el proyecto raíz"

OK, ahora me he mudado a git, y los submódulos SEEM son la nueva forma de lidiar con el código externo, pero parece que pierdo algunas características.

Es un proceso de múltiples pasos para obtener todas las dependencias del proyecto. Los desarrolladores de proyectos tienen que hacer un clon de git y luego una actualización de submódulo git submódulo init / git --recursiveEs un proceso de varios pasos para actualizar el proyecto raíz y el submódulo, por lo que si otro desarrollador realiza cambios en el proyecto raíz que coincidan con los cambios en el submódulo, no obtendrá el código correspondiente de inmediato y podría confundirseEl submódulo está bloqueado en una confirmación particular, y si realiza cambios en el submódulo, tendrá problemas para que funcione con la cabeza del motor compartido.No tengo control sobre qué revisión del motor compartido ha verificado el desarrollador del proyecto sin dar instrucciones sobre qué actualizar

Entonces mis preguntas son las siguientes:

En primer lugar, ¿son correctos los supuestos anteriores sobre los submódulos? Parece estar basado en lo que he leído, pero no estoy 100% seguro ya que todavía estoy descubriendo gitSi mis suposiciones son correctas, ¿estoy abordando el problema con el proceso correcto? ¿Necesito reajustar mi pensamiento cuando uso git? En otras palabras, ¿hay otra forma de hacer lo que estoy tratando de hacer y necesito pensar sobre el proceso de manera diferente?Suponiendo que no he volado los dos primeros, y los submódulos no harán lo que quiero, ¿qué hará? Leí sobre las fusiones de subárbol, pero tampoco parecen exactamente correctas, ya que parece que no puedo hacer que los cambios realizados en el código compartido vuelvan al repositorio.

Muchas gracias por su ayuda y paciencia. Si no es obvio, soy muy nuevo en git, y me gusta y quiero aceptarlo, pero todavía tengo algunos malentendidos conceptuales porque probablemente me han dañado el cerebro por años de usar repositorios centrales. ¡Quiero aprender! Además, he estado rtfm'ing todo el día, y mirando varias publicaciones de blog, preguntas de stackoverflow, etc., y todavía no lo entiendo, obviamente necesito que se explique paso a paso para mi situación. No tengo compañeros de trabajo para preguntar sobre esto, ¿hay algún grupo de usuarios en el área de Seattle donde pueda haber algunos git gurus? :)