sottomodulo git commit/push/pull

Question

Mi piacerebbe usare il sottomodulo git.

I passi che devo prendere per spingere le mie modifiche al mio progetto sono

1. add/commit/push dalla directory modulo
2. add/commit/spinta da directory padre

I passaggi che ho bisogno di prendere per tirare le modifiche del mio progetto.

1. git pull dalla directory padre
2. git aggiornamento modulo dalla directory padre

Passi per l'aggiornamento del modulo dalla sua repo originale

1. git pull da directory sottomodulo

Quello che mi preoccupa è il seguente exerpt da http://git-scm.com/book/en/Git-Tools-Submodules

Il problema è che in genere non si vuole lavorare in un ambiente HEAD indipendente, perché è facile perdere le modifiche. Se esegui un aggiornamento iniziale del modulo , esegui il commit nella directory del sottomodulo senza creare una filiale , quindi esegui di nuovo l'aggiornamento del sottomodulo git dal superprogetto senza commit nel frattempo, (?? update/commit/update perdere il cambio?) Git sovrascriverà le modifiche senza dirti. Tecnicamente non perderai il lavoro, ma non avresti un ramo che punta ad esso, quindi sarà un po ' difficile da recuperare.

Per evitare questo problema, creare un ramo quando si lavora in un sottomodulo nella directory con git checkout -b lavoro o qualcosa di equivalente. Quando esegui l'aggiornamento del sottomodulo una seconda volta, il tuo submodule ripristina il tuo lavoro, ma almeno hai un puntatore a cui tornare.

ho intenzione di modificare sottomoduli e non voglio rovinare, il doc sopra brevemente menziona la possibilità di perdere il cambiamento, e non capisco che cosa potrebbe causare la perdita.

Mi chiedo quali passi aggiuntivi più di quelli sopra elencati ho bisogno di prendere per evitare la perdita . Specialmente diversi membri del team modificano i sottomoduli, cosa devono fare per non rovinarsi?

Answer 1

Mi piacerebbe condividere le mie esperienze con voi come qualcuno che lavora con progetti esterni in soluzioni Visual Studio cercando di risolvere un problema simile. Sono relativamente nuovo da git, quindi se qualcuno ha delle critiche costruttive lo apprezzerei.

Se si utilizza Visual Studio, l'estensione Git Source Control Provider è gratuita (http://visualstudiogallery.msdn.microsoft.com/63a7e40d-4d71-4fbb-a23b-d262124b8f4c) e sembrava eseguire il commit in modo ricorsivo dei sottomoduli quando l'ho testato.

TUTTAVIA sto usando VS Web Developer Express a casa per lo sviluppo, quindi non voglio fare affidamento su un'estensione (penso anche che sia bello avere un'idea di cosa sta succedendo sotto il cofano). Quindi sono stato costretto a capire i comandi, e ho aggiunto alcune note di seguito.

NOTE

Se non si è già fatto, hanno una lettura approfondita attraverso http://git-scm.com/book/en/Git-Tools-Submodules. Ci sono alcuni avvertimenti, e farò riferimento a questa pagina. Se provi a lavorare con i sottomoduli senza leggerlo, ti darai un mal di testa molto velocemente.

Il mio approccio segue questo tutorial, con alcuni extra: http://blog.endpoint.com/2010/04/git-submodule-workflow.html

Una volta che avete la vostra SuperProject inizializzata (ad es git init & & git remote add origin ...), iniziare ad aggiungere i vostri sottomoduli in questo modo:

git submodule add git://github.com/you/extension1.git extension 
git submodule init 
git submodule update 

Controllare che il tuo file .gitmodules riflette questa aggiunta, ad es

[submodule "extension1"] 
     path = extension 
     url = git://github.com/you/extension1.git 

Passa alla directory modulo (vale a dire cd extension). Run:

git fetch #I use fetch here - maybe you can use pull? 
git checkout -b somebranchname #See the Git-Tools-Submodules link above for an explanation of why you need to branch 

Ho fatto un cambiamento qui per README.txt così ho potuto commetterlo (anche così avrei un record di quello che stavo facendo in questo commit), allora impegnato il modulo di applicare il ramo (ancora all'interno della directory modulo):

git add . 
git commit -a -m "Branching for extension submodule" 

passare nella SuperProject (cioè cd ..). Sarà inoltre necessario impegnarsi qui (se si guarda alla pagina di git modulo ho detto spiega perché ciò sia necessario):

git status #will show you that your submodule has been modified 
git commit -a -m "Commiting submodule changes from superproject" 

Ora possiamo spingere recusively i nostri progetti in questo modo, se necessario:

git push --recurse-submodules=on-demand 

È necessario eseguire i passaggi precedenti una volta per tutti i sottomoduli.

Una volta che avete fatto questo per tutti i vostri sottomoduli e iniziato a fare modifiche che si desidera impegnarsi e spingere, è possibile utilizzare:

git submodule foreach 'git add .' #recursively add files in submodules 

Unfortunaly non ho trovato un modo per impegnarsi in modo ricorsivo senza usare qualcosa di simile git-slave (chiunque?), Quindi è necessario andare in ogni directory del sottomodulo ed eseguire un commit regolare per i file appena aggiunti.Nella SuperProject:

git status #tells you that `extension` submodule has been modified 
cd extension 
git commit -a -m "Commiting extension changes in superproject edit session" 

Una volta che il modulo è commiting, avrete anche bisogno di commettere il SuperProject (di nuovo), in modo da:

cd .. 
git add . 
git commit -a -m "Altered extension submodule" 
git status #should now show 'working directory clean', otherwise commit other submodules in the same manner 

Questo può ottenere un po 'fastidioso (perché si finisce per commettere due volte), ma una volta che ne siete a conoscenza, in realtà non è così male (in quanto vi costringe a verificare ciò che state impegnando in ogni progetto). Solo la mia opinione - se hai isolato alcune delle funzionalità del tuo superproject nei sottomoduli, dovrebbe funzionare in modo indipendente dal resto dei tuoi progetti comunque (quindi commetterli in momenti diversi, mentre fastidiosi, non è la fine del mondo).

Ora siamo in grado di spingere ancora una volta ...

git push --recurse-submodules=on-demand 

Se poi si scende nel vostro modulo e cercare di spingere di nuovo, lo troverete non farà nulla come l'ultimo commit è già stato spinto.

La clonazione (o l'utilizzo di un'origine remota) per un superprogetto può anche essere piuttosto confusa, ad esempio la necessità di eseguire git submodule update due volte dopo git submodule init. Leggi la sezione "Clonazione di un progetto con sottomoduli" di http://git-scm.com/book/en/Git-Tools-Submodules.

Qualcosa che mi ha catturato quando ho clonato il mio superprogetto stava ottenendo le ultime modifiche per i sottomoduli. Vedere Easy way pull latest of all submodules

La mia variante di questo è di usare un ramo 'di sviluppo' per moduli ritirati (ma si può chiamare quello che vuoi) e quindi utilizzare questo nel SuperProject:

git submodule foreach git pull origin development 

Quando ho creato questo in su ho anche scambiare al ramo voglio spingere le mie modifiche per il modulo controllato in questo modo:

cd extension 
git checkout -b development #This will tell you this is a new branch, but I believe this means a new branch of the local git repository - this will get pushed to the 'development' branch 
#Make your changes, commit etc. 

posso confermare che, quando seguo i passaggi precedenti, le modifiche ai moduli di un clone/a distanza il progetto di origine (quando premuto) è apparso in un altro clone es/remote origini dello stesso progetto (non dimenticando l'ultimo comando pull submodule).

Spero che ti sia stato utile.