2009-03-17 11 views
12

J'utilise git pour m'interfacer avec un dépôt SVN. J'ai plusieurs branches git pour les différents projets sur lesquels je travaille.flux de travail git et C++, comment gérer les fichiers objet et archive?

Maintenant, chaque fois que je passe d'une branche à l'autre en utilisant 'git checkout', tous les exécutables compilés et les fichiers objets de la branche précédente sont toujours là. Ce que je voudrais voir, c'est que passer de la branche A à la B aboutit à une arborescence avec tous les fichiers objets et binaires de la dernière fois que j'ai travaillé sur la branche B.

Y at-il un moyen de gérer cela sans créer plusieurs dépôts git? ? Je comprends que les exécutables et les binaires ne doivent pas se retrouver dans le référentiel. Je suis un peu déçu du fait que toutes les branches de git sont inutiles pour moi, car il me faudra cloner mon dépôt git proxy pour chaque branche que je veux démarrer. Quelque chose que j'ai déjà fait pour SVN et espéré éviter avec git. Bien sûr, je n'ai pas besoin de le faire, mais cela me ferait faire une nouvelle marque la plupart du temps après avoir changé de branche (pas drôle).

+0

Vous devriez checkout différentes branches à des répertoires différents, ou vais-je recevoir votre question mal? – schnaader

+0

Pourquoi voulez-vous que les exécutables et les binaires soient dans le contrôle de la source? – n0rd

+0

Comme il est indiqué dans une réponse, une bonne solution consiste à construire dans un dossier séparé que les sources sont. Mais le clonage des dépôts git locaux est très rapide, donc ce n'est peut-être pas si grave. – Ismael

Répondre

9

Ce que vous voulez est un contexte complet, pas seulement la branche ... qui est généralement en dehors d'un outil de contrôle de version. La meilleure façon d'y parvenir est d'utiliser plusieurs référentiels.

Ne vous inquiétez pas de l'inefficacité de cela ... Faites de votre deuxième dépôt un clone de la première. Git utilisera automatiquement les liens pour éviter d'avoir plusieurs copies sur le disque.

Voici un hack pour vous donner l'envie vous voulez

Puisque vous avez des répertoires obj séparés, vous pouvez modifier votre Makefile pour rendre l'emplacement de base dynamique en utilisant quelque chose comme ceci:

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" 

Ce mais votre nom de branche dans OBJBASE, que vous pouvez utiliser pour construire votre emplacement réel objdir. Je vous laisse le soin de le modifier pour l'adapter à votre environnement et de le rendre convivial aux utilisateurs non-git de vos Makefiles.

1

Ces fichiers ne sont pas suivis par Git ou Subversion, ils sont donc laissés en suspens dans l'hypothèse où ils vous seraient utiles.

Je viens de faire mes caisses dans différents répertoires. Sauve-moi la peine de faire le nettoyage.

6

Ce n'est pas spécifique à git ou svn - vous devriez demander à votre compilateur et à d'autres outils de diriger la sortie des fichiers intermédiaires comme les fichiers .o vers les répertoires qui ne sont pas sous contrôle de version.

+0

Est-ce une pratique standard? Actuellement, notre arborescence est divisée en répertoires src séparés pour chaque module avec les répertoires obj et lib qui l'accompagnent. Des pointeurs sur la façon de le faire différemment (d'une manière standard)? –

+1

Peu importe où dans l'arbre ils sont tant que le contenu est exclu du contrôle par des mécanismes comme svn: ignore –

+2

Cela ne rendra pas les fichiers d'objets correspondant à son extraction. Il essaie d'éviter de «nettoyer» le changement de branche. –

3

Vous pouvez définir votre compilateur IDE pour générer tous les fichiers temporaires privés (.class et ainsi de suite) dans <output>\branchName\.... En configurant votre paramètre de compilation branche par branche, vous pouvez enregistrer le nom de la branche dans le chemin du répertoire de sortie. De cette façon, même si les fichiers privés restent quand vous git checkout, votre projet sur la nouvelle branche est prêt à partir.

3

Dans le répertoire contrib/ de la distribution git, il existe un script appelé git-new-workdir qui vous permet d'extraire plusieurs branches dans différents répertoires sans cloner votre référentiel.

0

Un make clean ne devrait pas être nécessaire car les fichiers qui sont différents entre les différentes branches sont vérifiés avec la date réelle !!! Cela signifie que si votre Makefile est correct, seuls les fichiers-objets, les librairies et les exécutables sont compilés de nouveau, ce qui a vraiment changé à cause de la commande. Ce qui est exactement la raison pour laquelle un makefile est là en premier lieu.

L'exception est si vous devez basculer les options du compilateur ou même les compilateurs dans différentes branches. Dans ce cas, git-new-workdir est probablement la meilleure solution.

5

Pour conserver plusieurs extractions du même référentiel, vous pouvez utiliser git --work-tree. Par exemple,

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

Si les exécutables compilés sont des fichiers qui ont été vérifiés dans
puis Stash git résout le problème.

[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...] 

Si les exécutables compilés sont des fichiers qui ne sont pas et ne seront pas vérifiés dans
puis les ajouter simplement .gitignore

Questions connexes