Pasticcio di sottotitoli Git: come usare i sottomoduli git con gli sviluppatori che non hanno familiarità con git?

Question

Sono davvero frustrato dall'uso della funzione di sottomodulo di git. O continuo a non farlo bene o semplicemente non funziona come mi aspetto. In seguito la situazione del progetto è dato:

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

In questo scenario fonte sta puntando ad un altro repository che contiene i dati di origine comuni in tutti i nostri progetti. C'è molto sviluppo in corso sotto fonte come anche sotto projsrc. Sfortunatamente Il progetto punta a qualche commit del sottomodulo di origine e non al HEAD effettivo di esso. Questo è il solito comportamento da idiota, per quanto ne so.

ho già scoperto che

git submodule update 

solo ottenere la versione del modulo che è stato commesso insieme al progetto principale. Tuttavia, mi piacerebbe davvero essere sempre aggiornato sullo sviluppo dei sottomoduli, ma non ho alcuna idea su come farlo correttamente. Quindi la mia domanda è:

E 'possibile collegare il Progetto alla TESTA del modulo, reagardless del fatto se questo si romperà la compilazione di progetto o meno. Solo non voglio andare sempre nel sottomodulo directory e fare git pull lì. Dal momento che penso che potrei perdere le mie modifiche fatte nella directory del sottomodulo, perché questo è semplice collegato a un commit e non proprio a qualsiasi ramo o così.

perche seguenti vincoli:

• sviluppatori nel nostro gruppo non sono che la familiarità con tutti i VCS intorno. Siamo abituati ad usare un repository svn davvero enorme prima, senza alcuna funzionalità di repository esterna.
• Stiamo lavorando su Windows
• Una soluzione click'n'forget sarebbe meglio, dal momento che la maggior parte dei membri del progetto sono piuttosto spaventati utilizzando un'interfaccia a riga di comando :)

Answer 1

il motivo per cui i punti sottomodulo a una particolare revisione è importante. Se si punta a un HEAD, le build saranno non riproducibili. Cioè se controlli la versione di ieri del Progetto, non sapresti mai quale versione esatta della fonte @ HEAD fosse ieri.

Ecco perché memorizza sempre particolari revisioni.

per tirare tutti i sottomoduli si potrebbe usare Easy way pull latest of all submodules

Answer 2

io non sono bravo a Git e modulo. Ma penso che alcune semplici regole sarebbero molto utili.

1. Conferma e push dalla sottodirectory.
2. Tornare alla radice del progetto, controllare lo stato se è necessario eseguire il commit e premere nuovamente.

quando Pull. può provare a usare lo script per raggruppare insieme l'aggiornamento "pull/submodule". E fallo solo alla radice del tuo progetto.

Answer 3

Considerate questo:

1. fonte sta puntando a testa (come si vorrebbe).
2. si apportano modifiche alla fonte all'interno di progetto (si commette ma non li si spinge)
3. ora si hanno due HEAD: uno nella fonte del progetto, un altro nella fonte comune.

Quale si vorrebbe essere presente nel progetto quando si effettua l'aggiornamento del modulo di sottomodulo?

Il problema (e la caratteristica principale) di git nel tuo caso è che consideri commit e push come operazione atomica. Non lo è. Git è decentrato. Non esiste un HEAD comune. Potresti avere più repository con HEAD diversi.

Considerate questo:

1. si dispone di 3 sviluppatori (A, B e C) con un progetto Git.
2. tutti tirano il TESTO di un progetto.
3. ogni sviluppatore ha apportato modifiche al progetto
4. ora ognuna di esse ha 3 TEST: A TESTA, A TESTA B A TESTA C.

Quale TESTE consideri "vero" TESTA?

Quindi, per rispondere alla tua domanda: Se vuoi che il sottomodulo sorgente comune sia sempre sincronizzato con il repository centrale, git non è la tua scelta. E probabilmente nessuno dei VCS ti può aiutare in questo.

Si dovrebbe trattare git modulo come una libreria di terze parti che dovrebbe essere aggiornato manualmente con questi due passaggi:

1. tirare il modulo ("scarica libreria di terze parti")
2. Commit il vostro progetto con modulo aggiornato (" inserire la nuova versione della libreria di terze parti al progetto ")

Se si desidera apportare modifiche al modulo si dovrebbe fare lo stesso in senso inverso:

1. Commit tuo modulo ("apportare le modifiche alla libreria di terze parti")
2. spingere il modulo ("invia le modifiche al manutentore libreria di terze parti")
3. Commit il vostro progetto con modulo aggiornato ("inserire la nuova versione della libreria di terze parti al progetto ")