Asesoramiento de flujo de trabajo del submódulo de Git

Question

Así que comencé a usar Git hace unos días. (Muy tarde para la fiesta - no regañe :)). Realmente comenzando a sentirme cómodo con los comandos básicos, ideas y flujos de trabajo. Sin embargo, los submódulos realmente me llevan a mi cerebro a dar un paseo. Estoy intentando contribuir con el código FuelPHP 's GitHub y podría utilizar algunas pautas y consejos.

estoy ejecutando los siguientes comandos en el terminal:

//1: clone the repository from Fuel's github. 
git clone git://github.com/fuel/fuel.git 

//2: move into the main fuel directory 
cd fuel 

//3: initilize the submodules (populate .git/config with submodule data) 
git submodule init 

//4: download the submodules... 
git submodule update 

//5: move into the core directory (which is a submodule). 
cd fuel/core 

//6: change branch from (*no branch) to 1.1/develop 
git checkout 1.1/develop 

//7: open random file in text editor + make some small change (i.e. typo) + save file. 
sudo gedit classes/autoloader.php 

//8: add this file to the staging area. 
git add classes/autoloader.php 

//9: commit this file under 1.1develop branch. 
git commit -m "im committing a submodule" 

//10: push the new commit to MY (not fuel's) github repo (yes i've renamed the repo). 
git push git@github.com:jordanarseno/fuel-core.git 

//11: changes are reflected on github, looks good. 

//12: back way out to fuel again. time to push the submodule commit separately. 
cd ../../ 

//13: add the fuel/core submodule to the staging area. 
git add fuel/core 

//14: commit the submodule change. 
git commit -m "submodule pushed. pushing super now." 

//15: push the commit to MY (not fuel's) github repo. 
git push git@github.com:jordanarseno/fuel.git 

Específicamente, mis preguntas son:

1. Es este el flujo de trabajo adecuado para el uso de cartuchos? ¿Es lo que harías?
2. ¿Por qué git pull down la rama 1.1/develop en un submódulo pero me ha puesto sobre *no branch por defecto? ¿Puedo modificar este comportamiento?
3. ¿Qué parte del submódulo de combustible le dice a Git para tirar 1.1/desarrollar en primer lugar? Hay otras ramas (1.1/master, 1.0/develop etc ..).
4. ¿Por qué no podemos llamarlo un día en el paso 11? El empuje del submódulo funcionó bien. Empujo el super después porque el manual tells me it's a good idea. Y, de hecho, dirigiéndome a GitHub y mirando a MI super, se hace un compromiso. This commit 845de87, sin embargo, parece ser solo una referencia al super de Fuel y no a MY super. ¿No debería vincularse a MI repositorio y no a los suyos?
5. Correr cat .git/config en Super Shows:

Junto con todos los submódulos ...

[remote "origin"] 
fetch = +refs/heads/*:refs/remotes/origin/* 
url = git://github.com/fuel/fuel.git` 

Correr cat .git config en el sub-módulo central muestra:

[remote "origin"] 
fetch = +refs/heads/*:refs/remotes/origin/* 
url = git://github.com/fuel/core.git 

¿Sería aconsejable cambiar estas URL a MI propio repositorio en GitHub? El combustible niega los empujes de todos modos. Si realizo una actualización de submódulo, ¿se sobrescribirán?

También he pedido esto en Fuel's Forums, pero es más una pregunta general y hay más Gitters aquí ... ¡GRACIAS!

Answer 1

1. Sí, como se explica en "true nature of submodules"

2. un submódulo git es una referencia a un compromiso específico (SHA1), no una rama, para que siempre esté en un modo de separar una primera (que es compatible con un uso de solo lectura).
   En otras palabras, git submodule update desprotege un específico comprometen, en lugar de la punta de una rama.
   El archivo .gitmodule contendrá la referencia de su cesión temporal submódulo. Y el SHA1 específico se registrará en el repositorio principal como una confirmación especial (modo 160000). Cuando 'git submodule add' un nuevo submódulo, registra el SHA1 en el que ese otro repositorio está actualmente prestado (cualquiera que sea su sucursal).
   Si desea realizar cambios, debe verificar una rama dentro de ese repositorio de submódulos (una rama existente o una nueva: en ambos casos, volverá a enviar cualquier cambio nuevo al repositorio remoto de ese submódulo).
   Una alternativa sería git slave.

3. Ver 2. La otra rama (s) que aparece en el git branch son la local existente en su repo submódulo, incluyendo una rama local de cada tracking branch si se hizo un git pull en un punto.

4. Porque el elemento primario sigue haciendo referencia al SHA1 inicial del submódulo.
   Pero como ha realizado modificaciones, SHA1 debe actualizarse.
   Tenga en cuenta que el submódulo es un git repo en sí mismo ... sin ninguna idea, se utiliza como un submódulo. De ahí la necesidad de registrar el nuevo estado de ese repositorio en el repositorio principal (el único que realiza un seguimiento del estado de sus submódulos).
   Su primera pulsación de git es completamente una operación interna del repositorio de submódulo (que no se ve en absoluto por el repositorio principal).
   Para un repositorio principal, el repositorio del submódulo es un "recuadro negro", con solo una dirección remota y un SHA1. Lo que se hace dentro del submódulo no tiene consecuencias en el padre, que detectará solo el cambio del SHA1 del árbol del submódulo.

5. Usando forks podría ayudar
   Ver "Changing remote repository for a git submodule" actualizar la URL remota submódulo.