Qu'en est-il du projet Eclipse .metadata puis-je ignorer en toute sécurité dans Git / Mercurial?
Nous avons le code d'une application Eclipse RCP dans un espace de travail Eclipse contenant plusieurs Java. Nous utilisons Mercurial avec un simple .hgignore juste * .class (mais le même problème concernerait Git) .
Même une petite modification du code peut entraîner la modification de nombreux fichiers en .metadata.
Je voudrais exclure une partie ou la totalité des .metadata du contrôle de version. Si nous l'excluons complètement, l'espace de travail est perdu.
Quelqu'un sait-il ce que nous pouvons exclure en toute sécurité? Sinon, comment pouvons-nous le recréer si nous tirons le code vers un nouvel ordinateur?
Les fichiers que je connais personnellement sont:
- version.ini (pas très excitant)
- .plugins/org.Eclipse.jdt.core/variablesAndContainers.dat (variables de chemin de classe)
- .plugins/org.Eclipse.core.resources/.projects/* /. location (projets dans l'espace de travail)
Quelque part, j'ai un espace de travail Eclipse utilisé pour tester certains outils liés à Eclipse qui est assez sévèrement réduit, mais qui fonctionne. Je vais voir si je peux le creuser.
GitHub gère un projet de communauté "gitignore" qui catalogue les suggestions de fichiers à ignorer pour diverses plates-formes, éditeurs et langues: https://github.com/github/gitignore
Les ignorés d'Eclipse sont ici: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore
(S'il y a d'autres spécifications de fichiers à connaître, faites-le-leur savoir!)
Métadonnées et espace de travail
Je ne partagerais jamais le dossier .metadata. En fait, sauf si vous avez une raison particulière, je ne partagerais même pas le dossier de l'espace de travail, mais plutôt partager chaque projet séparément avec git. De cette façon, le dossier .metadata Sera toujours dans le dossier parent de votre dépôt git et vous n'avez pas à vous demander si vous devez l'ignorer de toute façon:
|-- workspace/
| \-- .metadata/
| |-- yourProjectOne/
| | \-- .git/
| | |-- .project
| | |-- src/
| | |-- ...
| |-- yourProjectTwo/
| | \-- .git/
| | |-- .project/
| | |-- src/
| | |-- ...
Spécifique au projet
Vous devriez probablement toujours partager le fichier .project Et jamais les fichiers .settings/. Le .classpath Peut dépendre de votre environnement mais je ne suggérerais pas de le partager non plus, car il peut provoquer des conflits (par exemple si un utilisateur utilise openjdk et l'autre utilise Sun-jdk. Le .settings contient des préférences et des paramètres pour Eclipse et change beaucoup, donc il ne doit pas être partagé. Si vous importez correctement le projet après l'avoir cloné depuis git, vous n'aurez également aucun problème.
documentation Eclipse indique ce qui suit à propos du fichier .project:
Le but de ce fichier est de rendre le projet auto-descriptif, afin qu'un projet compressé ou publié sur un serveur puisse être correctement recréé dans un autre espace de travail.
et:
Si un nouveau projet est créé à un emplacement qui contient un fichier de description de projet existant, le contenu de ce fichier de description sera honoré en tant que description de projet. Une exception est que le nom du projet dans le fichier sera ignoré s'il ne correspond pas au nom du projet en cours de création. Si le fichier de description sur le disque n'est pas valide, la création du projet échouera.
Je suggère également d'utiliser Maven car cela vous évitera beaucoup de problèmes avec la gestion des dépendances et .classpath
Maven
La principale différence avec un projet Maven est que vous pouvez importer le projet en tant que Maven -> "Projets Maven existants" et donc avoir seulement besoin de partager le fichier pom.xml et .project Dans git. Eclipse créera alors automatiquement les fichiers .classpath, .settings/ Pour vous. Ainsi, vous n'avez évidemment pas besoin de les partager. Si quelque chose change dans pom.xml, vous exécutez simplement Maven -> "Mettre à jour la configuration du projet" et Maven -> "Mettre à jour les dépendances".
Sans Maven
Vous devez partager le fichier .project Et non le dossier .settings/. Vous pouvez envisager de partager .classpath mais cela peut entraîner des conflits comme expliqué ci-dessus. Je suggérerais de ne pas le partager non plus. Utilisez la méthode ci-dessous pour importer le projet:
Après avoir cloné le référentiel git, vous pouvez simplement utiliser Importer -> "Projet existant depuis l'espace de travail" Eclipse honorera le fichier .project Mais recréera les fichiers .classpath Et .settings/. Après l'importation, vous devrez configurer le chemin de classe manuellement depuis Eclipse (et chaque fois que votre équipe souhaite utiliser une autre bibliothèque).
Si vous ne partagez pas le fichier .project, il n'est pas possible d'importer le projet avec Eclipse. Vous devrez d'abord créer un nouveau projet avec l'assistant de projet, puis choisir d'importer "Général-> Système de fichiers", cela copiera tous les fichiers dans votre espace de travail. Ce n'est probablement pas ce que vous voulez, car cela signifie que vous ne pouvez pas cloner le référentiel git dans l'espace de travail, vous devez le cloner ailleurs et ensuite l'importer à partir de là. Par conséquent, vous devez toujours partager le fichier .project.
Merci de laisser un commentaire si vous avez des suggestions pour cette explication ou si vous n'êtes pas d'accord avec elle. J'espère que cela aide l'un ou l'autre.
Les métadonnées de l'espace de travail ne doivent vraiment pas être conservées dans le contrôle de code source. La configuration de base de l'espace de travail peut être partagée via un ensemble de projets d'équipe .
Je garde régulièrement .project et .classpath, non seulement ils sont sûrs pour git mais aussi utiles.
.class et .settings sont dans mon gitignore. Celles-ci sont générées et spécifiques à chaque personne.