¿Cómo se adapta mi estrategia svn: externals a los submódulos de git?

Question

Tengo problemas para descubrir cómo cambiar mi modo de pensar a git y me he encontrado con el siguiente problema. Tengo la situación en la que tenemos un motor compartido y varios proyectos que usan el motor. Los equipos internos de desarrollo 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 unas pocas semanas antes del envío, donde se etiquetará el motor compartido. y ramificado, y el proyecto usará esa rama. Los equipos de proyecto normalmente solo trabajan en un proyecto a la vez, pero pueden realizar cambios en el motor compartido durante la depuración o agregar funciones. Cuando comprometen esos cambios, nuestro sistema de compilación se ejecuta para encontrar cualquier problema que puedan haber introducido con la confirmación.

I (creo que) quiero utilizar este mismo modelo con un nuevo proyecto/nueva compañía. En SVN, la estructura fue 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 podían hacer una orden de revisar todas las dependencias que necesitarían
• Los desarrolladores de proyectos podría hacer el trabajo del motor y comprometerse en el motor compartido fácilmente
• Podríamos fácilmente rev o cambiar el motor compartido que el proyecto estaba utilizando con externos y revisiones
• actualizaciones del motor eran fáciles de conseguir con su "actualización del proyecto raíz" diaria

bien, ahora me he mudado a Git, y submódulos parecen ser la nueva manera de tratar con código externo, pero parece que pierdo algunas características.

• Es un proceso de varios pasos para obtener realmente todas las dependencias del proyecto. Los desarrolladores de proyectos tienen que hacer una clonación git luego una actualización del submódulo git submódulo init/git --recursive
• Es un proceso de múltiples pasos para actualizar el proyecto raíz y el submódulo, por lo que si otro desarrollador hace cambios en el proyecto raíz coinciden los cambios en el submódulo, no obtiene el código coincidente inmediatamente y podría confundirse
• El submódulo está bloqueado a una confirmación en particular, y si realiza cambios en el submódulo, tendrá problemas para hacerlo funcionar con el jefe del motor compartido
• No tengo control sobre la revisión del motor compartido que el desarrollador del proyecto ha revisado sin dar instrucciones sobre qué actualizar a

Así que mis preguntas son las siguientes:

• En primer lugar, son los supuestos anteriores sobre submódulos correcta? Parece estar basado en lo que he leído, pero no estoy 100% seguro ya que aún estoy averiguando git
• Si mis suposiciones son correctas, ¿me estoy acercando al problema con el proceso correcto? ¿Debo reajustar mi pensamiento al usar git? En otras palabras, ¿hay alguna otra manera de hacer lo que estoy tratando de hacer y necesito pensar sobre el proceso de manera diferente?
• Suponiendo que no he explotado los dos primeros, y los submódulos no harán lo que quiero, ¿qué lo hará? Leí acerca de las combinaciones de subárboles pero tampoco parecen exactamente correctas, ya que parece que no puedo hacer cambios en el código compartido en el repositorio.

Muchas gracias por su ayuda y paciencia. Si no es obvio, soy muy nuevo en git, y me gusta y quiero abrazarlo, 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 trabajando todo el día y mirando varias publicaciones de blogs, preguntas de stackoverflow, etc., y todavía no lo entiendo, obviamente necesito que se detalle paso por paso para mi situación. No tengo compañeros de trabajo para preguntar sobre esto, ¿algún grupo de usuarios en el área de Seattle donde podría haber algunos git gurus? :)

Answer 1

Tienes razón en que un submódulo siempre hace referencia a una revisión específica, que se fija cuando git add el directorio submódulo (y por lo tanto se puede controlar exactamente lo que está desprotegido en el cuadro de desarrollador). Pero veo esto como una característica, ya que siempre puedes solicitar la CABEZA de un submódulo cuando lo necesites. Por otro lado, esto significa que siempre obtendrás el mismo estado cuando pagues un viejo estado de tu proyecto, independientemente de lo que haya cambiado en los submódulos. Puede pensar en ellos como svn externos que están anclados a una revisión específica.

En cuanto a los cambios en el submódulo, son solo repositorios git normales, donde puede trabajar con su flujo de trabajo normal, como si estuvieran clonados en una copia de trabajo propia. Hay una diferencia con respecto a un clon regular, que la salida de un submódulo es muy probable que se trate de una cabeza separada, por lo que debe crear una rama por su cuenta cuando realice cambios allí.

Para la parte de muchos comandos, sí, hay una necesidad de hacer más trabajo, ese es el precio a pagar por esta característica. Puede agregar una secuencia de comandos que realice la extracción de submódulos si hay muchos de ellos.

EDITAR

He encontrado una explicación detallada acerca de submódulos: http://longair.net/blog/2010/06/02/git-submodules-explained/.