2009-03-17 6 views
12

Io uso git per interfacciare un repository SVN. Ho diversi rami di git per i diversi progetti su cui lavoro.flusso di lavoro git e C++, come gestire oggetti e file di archivio?

Ora, ogni volta che passo da un ramo all'altro utilizzando 'git checkout', tutti gli eseguibili compilati ei file oggetto dal ramo precedente sono ancora lì. Quello che mi piacerebbe vedere è che il passaggio dal ramo A al B produce un albero con tutti i file oggetto e binari dell'ultima volta che ho lavorato sul ramo B.

C'è un modo per gestire questo senza creare più repository git ?

Aggiornamento: Capisco che file eseguibili e binari non dovrebbero finire nel repository. Sono un po 'deluso dal fatto che tutta la roba di branching in git sia inutile per me, visto che dovrò clonare il mio repository git proxy per ogni ramo che voglio avviare. Qualcosa che ho già fatto per SVN e speravo di evitare con git. Certo, non ho bisogno di farlo, ma mi porterebbe a fare un nuovo make la maggior parte del tempo dopo il passaggio tra i rami (non è divertente).

+0

Si dovrebbe checkout diversi rami di diverse directory, o ottengo la tua domanda sbagliata? – schnaader

+0

Perché vuoi eseguire eseguibili e binari nel controllo del codice sorgente? – n0rd

+0

Come indicato in una risposta, una buona soluzione è creare in una cartella separata dove si trovano le fonti. Ma la clonazione dei repository git locali è molto veloce, quindi potrebbe non essere poi così male. – Ismael

risposta

9

Quello che vuoi è un contesto completo, non solo il ramo ... che è generalmente fuori portata per uno strumento di controllo della versione. Il modo migliore per farlo è utilizzare più repository.

Non preoccuparti dell'inefficienza di questo però ... Rendi il tuo secondo repository un clone del primo. Git utilizzerà automaticamente i collegamenti per evitare di avere più copie su disco.

Ecco un trucco per dare si vuole si vuole

Dal momento che hai directory obj separati, è possibile modificare il vostro Makefile per rendere la posizione di base dinamico usando qualcosa di simile:

OBJBASE = `git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1\//'` 
OBJDIR = "$(OBJBASE).obj" 
# branch master: OBJBASE == "master/", OBJDIR == "master/.obj" 
# non-git checkout: OBJBASE == "", OBJDIR == ".obj" 

Quello farà solo il nome del tuo ramo in OBJBASE, che puoi usare per creare la tua posizione oggettiva. Lascio a te la modifica per adattarlo al tuo ambiente e renderlo amichevole agli utenti non-git dei tuoi Makefile.

1

Questi file non sono tracciati da Git o da Subversion, quindi vengono lasciati da soli supponendo che siano di qualche utilità per te.

Ho appena effettuato il checkout in diverse directory. Mi risparmia la fatica di fare pulizia.

6

Questo non è specifico per git o svn: il tuo compilatore e altri strumenti devono indirizzare l'output di file intermedi come i file .o in directory che non sono sotto controllo di versione.

+0

Questa è una pratica standard? Attualmente il nostro albero è diviso in directory src separate per ogni modulo con le relative directory obj e lib. Qualche suggerimento su come farlo in modo diverso (in un modo standard)? –

+1

Non importa in che punto dell'albero ci sono finchè i contenuti sono esclusi dal controllo da meccanismi come svn: ignora –

+2

Questo non farà corrispondere i file oggetto al suo checkout. Sta cercando di evitare di "fare pulizia" sul cambio di filiale. –

3

È possibile impostare il compilatore IDE per generare tutti i file temporanei privati ​​(.class e così via) in <output>\branchName\....

Configurando la propria impostazione di compilazione ramo per ramo, è possibile registrare il nome del ramo nel percorso della directory di output.

In questo modo, anche se i file privati ​​rimangono quando si git checkout, il progetto sul nuovo ramo è pronto per essere utilizzato.

3

Nella directory contrib/ della distribuzione git, è presente uno script denominato git-new-workdir che consente di eseguire il checkout di rami multipli in diverse directory senza clonare il repository.

0

Un make clean non dovrebbe essere necessario perché i file diversi tra i vari rami vengono controllati con la data effettiva !!!

Ciò significa che se il Makefile è corretto, solo i file oggetto, le librerie e gli eseguibili vengono ricompilati e modificati in seguito al checkout. Quale è esattamente la ragione per cui un makefile è lì in primo luogo.

L'eccezione è se è necessario cambiare le opzioni del compilatore o anche i compilatori in rami diversi. In tal caso probabilmente git-new-workdir è la soluzione migliore.

5

Per mantenere più checkout dello stesso repository, è possibile utilizzare git --work-tree. Per esempio,

mkdir $BRANCH.d 
GIT_INDEX_FILE=$BRANCH.index git --work-tree $BRANCH.d checkout $BRANCH 
0

Se gli eseguibili compilati sono i file che sono stati controllati in
poi scorta git risolve il problema.

[compile] 
git stash save "first branch" 
git checkout other_branch 
[Fiddle with your code] 
[compile] 
git stash save "second branch" 
git checkout first_branch 
git stash apply [whatever index your "first branch" stash has] 
# alternatively git stash pop [whatever index...] 

Se gli eseguibili compilati sono file che non hanno e non sarà controllato in
poi semplicemente aggiungerli ad .gitignore