Questa pagina GitPro riassume bene le conseguenze di un aggiornamento del sottomodulo git
Quando viene eseguito git submodule update, verifica la versione specifica del progetto, ma non all'interno di un ramo. Questo si chiama avere una testa staccata - significa che il file HEAD punta direttamente a un commit, non a un riferimento simbolico.
Il problema è che in genere non si desidera lavorare in un ambiente distaccato, perché è facile perdere le modifiche .
Se esegui un aggiornamento iniziale del sottomodulo, esegui il commit in quella directory del sottomodulo senza creare un ramo su cui lavorare, quindi esegui nuovamente git submodule update dal superprogetto senza impegnarti nel frattempo, Git sovrascriverà le modifiche senza dirtelo. Tecnicamente non perderai il lavoro, ma non avrai un ramo che lo punta, quindi sarà un po 'difficile da recuperare.
Nota marzo 2013:
Come menzionato in " ultimo monitoraggio del sottomodulo git ", un sottomodulo ora (git1.8.2) può tracciare un ramo.
# add submodule to track master branch
git submodule add -b master [URL to Git repo];
# update your submodule
git submodule update --remote
# or (with rebase)
git submodule update --rebase --remote
Vedi " git submodule update --remotevsgit pull ".
La risposta di MindTooth illustra un aggiornamento manuale (senza configurazione locale):
git submodule -q foreach git pull -q origin master
In entrambi i casi, ciò cambierà i riferimenti dei sottomoduli (il gitlink , una voce speciale nell'indice repo principale ) e sarà necessario aggiungere, eseguire il commit e inviare tali riferimenti dal repository principale.
La prossima volta che clonerai quel repository principale, popolerà i sottomoduli per riflettere quei nuovi riferimenti SHA1.
Il resto di questa risposta descrive in dettaglio la classica funzionalità del sottomodulo (riferimento a un commit fisso , che è il punto centrale dietro l'idea di un sottomodulo).
Per evitare questo problema, crea un ramo quando lavori in una directory di sottomodulo con git checkout -b work o qualcosa di equivalente. Quando esegui l'aggiornamento del sottomodulo una seconda volta, ripristinerai comunque il tuo lavoro, ma almeno hai un puntatore a cui tornare.
Anche cambiare i rami con i sottomoduli può essere complicato. Se si crea un nuovo ramo, aggiungere un sottomodulo lì, e quindi tornare a un ramo senza quel sottomodulo, la directory del sottomodulo rimane comunque come directory non tracciata:
Quindi, per rispondere alle tue domande:
posso creare rami / modifiche e usare push / pull proprio come farei nei normali repository, o ci sono cose di cui fare attenzione?
È possibile creare un ramo e inviare modifiche.
ATTENZIONE (da Git Submodule Tutorial ): pubblicare sempre (push) la modifica del sottomodulo prima di pubblicare (push) la modifica nel superprogramma che la fa riferimento. Se si dimentica di pubblicare la modifica del sottomodulo, gli altri non saranno in grado di clonare il repository.
come avanzerei il commit del sottomodulo referenziato da dire (taggato) da 1.0 a 1.1 (anche se il capo del repository originale è già a 2.0)
La pagina " Comprensione dei sottomoduli " può essere d'aiuto
I sottomoduli Git sono implementati usando due parti mobili:
- il
.gitmodulesfile e
- un tipo speciale di oggetto ad albero.
Questi insieme triangolano una revisione specifica di un repository specifico che viene estratto in una posizione specifica nel progetto.
Dalla pagina del sottomodulo git
non è possibile modificare il contenuto del sottomodulo dall'interno del progetto principale
100% corretto: non è possibile modificare un sottomodulo, fare riferimento solo a uno dei suoi commit.
Ecco perché, quando modifichi un sottomodulo dall'interno del progetto principale, tu:
- è necessario eseguire il commit e l'invio all'interno del sottomodulo (al modulo upstream) e
- quindi passa al progetto principale e esegui nuovamente il commit (affinché quel progetto principale faccia riferimento al nuovo commit del sottomodulo appena creato e inviato)
Un sottomodulo consente di avere uno sviluppo di approccio basato su componenti , in cui il progetto principale fa riferimento solo a commit specifici di altri componenti (qui "altri repository Git dichiarati come sottomoduli").
Un sottomodulo è un marker (commit) in un altro repository Git che non è vincolato dal ciclo di sviluppo del progetto principale: esso (l '"altro" repository Git) può evolversi indipendentemente.
Spetta al progetto principale scegliere dall'altro repository qualsiasi impegno di cui abbia bisogno.
Tuttavia, se desideri, per comodità , modificare uno di quei sottomoduli direttamente dal tuo progetto principale, Git ti consente di farlo, a condizione che tu prima pubblichi quelle modifiche del sottomodulo al suo repository Git originale e quindi esegua il commit del tuo progetto principale facendo riferimento a una nuova versione di detto sottomodulo.
Ma l'idea principale rimane: fare riferimento a componenti specifici che:
- hanno il loro ciclo di vita
- hanno il proprio set di tag
- hanno il loro sviluppo
L'elenco di specifici commit a cui ti riferisci nel tuo progetto principale definisce la tua configurazione (questo è il concetto di Configuration Management, che comprende il semplice sistema di controllo versione )
Se un componente potesse davvero essere sviluppato contemporaneamente al tuo progetto principale (poiché qualsiasi modifica al progetto principale implicherebbe la modifica della sottodirectory e viceversa), non sarebbe più un "sottomodulo", ma un subtree merge (presentato anche nella domanda Trasferimento legacy code base da cvs a repository distribuito ), collegando insieme la cronologia dei due repository Git.
Ciò aiuta a comprendere la vera natura dei sottomoduli Git?