Lío de submódulos de Git: cómo usar submódulos de git con desarrolladores que no están familiarizados con git?

Question

Estoy realmente frustrado acerca del uso de la función de submódulo de git. O todavía no lo entiendo bien o simplemente no funciona ya que estoy esperando esto. A raíz de la situación del proyecto se da:

Project 
    | .git 
    | projsrc 
    | source (submodule) 
    | proj.sln 

En este escenario fuente está apuntando a otro repositorio que contiene los datos de origen comunes en todos nuestros proyectos. Hay un montón de desarrollo sucediendo bajo fuente como también en projsrc. Desafortunadamente El proyecto apunta a un compromiso del submódulo de origen y no a la CABEZA real del mismo. Este es el comportamiento habitual de git, por lo que yo sé.

ya descubrí que

git submodule update 

acaba de obtener la versión del submódulo que se compromete junto con el proyecto principal. Sin embargo, me gustaría estar siempre al día con el desarrollo de los submódulos, pero no tengo ninguna pista real de cómo hacerlo bien. De ahí mi pregunta es:

¿Es posible conectar el Proyecto a la cabeza del submódulo, independencia del arte empleado el hecho de si esto va a romper la compilación de proyecto o no. Simplemente no quiero entrar siempre en el directorio del submódulo y hacer git pull allí. Dado que creo que podría perder los cambios realizados en el directorio del submódulo, porque esto es simple adjuntado a una confirmación y no a ninguna rama más o menos.

Por favor, tener en cuenta las limitaciones siguientes:

• desarrolladores en nuestro grupo no son tan familiarizados con todas las VCS alrededor. Estamos acostumbrados a usar un enorme repositorio de svn antes, sin ninguna función de repo externo.
• Estamos trabajando en Windows
• Una solución click'n'forget sería mejor, ya que la mayoría de los miembros del proyecto son bastante miedo mediante el uso de una interfaz de línea de comandos :)

Answer 1

La razón para que un submódulo puntos para una revisión particular es importante. Si apunta a HEAD, las compilaciones serán unreproducible. Es decir. si realiza el checkout de una versión del proyecto de ayer, nunca sabría qué versión exacta de source @ HEAD era ayer.

Es por eso que siempre almacena sha de revisión en particular.

Para tirar de todos los submódulos que podría utilizar Easy way pull latest of all submodules

Answer 2

no soy bueno en Git y submódulo. Pero creo que algunas reglas simples serían muy útiles.

1. Confirmar y presionar desde el subdirectorio.
2. Regrese a la raíz de su proyecto, verifique el estado si necesita confirmar y volver a presionar.

cuando Tire. puede intentar usar script para agrupar la "actualización de extracción/submódulo". Y solo hazlo en la raíz de tu proyecto.

Answer 3

Considera:

1. fuente está apuntando a la cabeza (tal como esperaría que).
2. realiza cambios en la fuente dentro de usted Proyecto (confirma pero no los empuja)
3. ahora tiene dos HEAD: uno en el origen de su proyecto, otro en su fuente común.

¿Cuál quieres que esté presente en tu proyecto cuando realizas la actualización del submódulo?

El problema (y la característica principal) de git en su caso es que usted considera commit y push como operación atómica. No lo es Git está descentralizado. No hay CABEZA común. Es posible que tenga varios repositorios con diferentes HEAD.

Considera:

1. tienes 3 desarrolladores (A, B y C) con un proyecto Git.
2. todos ellos extraen la CABEZA de un proyecto.
3. cada desarrollador ha realizado cambios en el proyecto
4. ahora cada uno de ellos tiene 3 CABEZALES: A HEAD, B HEAD y C HEAD.

¿Qué CABEZA considera "verdadera" CABEZA?

Por lo tanto, para responder a su pregunta: Si desea que el submódulo fuente común siempre se sincronice con el repositorio central, git no es su elección. Y probablemente ninguno de los VCS te ayude con eso.

Debe tratar submódulo git como una biblioteca thirdparty que debe ser actualizado manualmente con estos dos pasos:

1. tirar de su submódulo ("descarga biblioteca thirdparty")
2. confirme su proyecto con submódulo actualizado (" colocar la nueva versión de la biblioteca thirdparty a su proyecto ")

Si desea realizar cambios a submódulo usted debe hacer lo mismo en orden inverso:

1. Commit su submódulo ("hacer sus cambios en la biblioteca thirdparty")
2. empujar su submódulo ("enviar los cambios a la thirdparty mantenedor biblioteca")
3. confirme su proyecto con submódulo actualizado ("lugar de la nueva versión de la biblioteca de terceros para su proyecto ")