Que puis-je ignorer en toute sécurité dans le projet Eclipse .metadata dans Git/Mercurial?

Question

Nous avons le code pour une application Eclipse RCP dans un espace de travail Eclipse contenant plusieurs projets Java. Nous utilisons Mercurial avec un simple .hgignore juste * .class (mais le même problème concernerait Git).

Même une petite modification apportée au code peut entraîner la modification de nombreux fichiers .metadata.

Je souhaite exclure tout ou partie du fichier .metadata du contrôle de version. Si nous l'excluons complètement, l'espace de travail est perdu. Est-ce que quelqu'un sait ce que nous pouvons exclure en toute sécurité? Alternativement, comment pouvons-nous le recréer si nous tirons le code vers un nouvel ordinateur?

Answer 1

Les fichiers que je suis personnellement au courant sont:

• version.ini (pas très excitant)
• .plugins/org.eclipse.jdt.core/variablesAndContainers.dat (variables classpath)
• .plugins/org.eclipse.core.resources/.projects/* /. emplacement (projets dans l'espace de travail)

quelque part, j'ai un espace de travail Eclipse utilisé pour tester des outils liés à Eclipse qui est assez sévèrement abattu, b ut œuvres. Je vais voir si je peux le déterrer.

Answer 2

Les métadonnées de l'espace de travail ne doivent en réalité 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 team project set.

Answer 3

Je garde régulièrement .project et .classpath, non seulement ils sont sûrs pour git mais utiles.

.class et .settings sont dans mon gitignore. Ceux-ci sont générés et spécifiques à la personne respectivement.

Answer 4

GitHub maintient un projet "gitignore" communautaire que les catalogues ont suggéré filespecs pour ignores pour différentes plates-formes, les éditeurs et les langues: https://github.com/github/gitignore

Eclipse ignores sont ici: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore

(S'il y a d'autres filespecs qu'ils devraient savoir, leur faire savoir!)

Answer 5

Métadonnées et Espace de travail

I wou Je ne partage jamais le dossier .metadata. En fait, à moins d'avoir une raison particulière, je ne partagerais même pas le dossier de l'espace de travail mais je partagerais 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 ne devez pas penser à si vous avez besoin de l'ignorer quand même:

|-- workspace/ 
| \-- .metadata/ 
| |-- yourProjectOne/ 
| | \-- .git/ 
| | |-- .project 
| | |-- src/ 
| | |-- ... 
| |-- yourProjectTwo/ 
| | \-- .git/ 
| | |-- .project/ 
| | |-- src/ 
| | |-- ... 

Projet spécifique

Vous devriez probablement toujours partager le fichier .project et jamais .settings/ fichiers. Le .classpath peut dépendre de votre environnement mais je ne suggérerais pas de le partager non plus, car cela peut provoquer des conflits (par exemple si un utilisateur utilise openjdk et l'autre utilise sun-jdk.Le .settings contient les préférences et les paramètres pour eclipse et change beaucoup, il ne doit donc pas être partagé. Si vous importez correctement le projet après l'avoir cloné depuis git, vous n'aurez plus aucun problème.

Les eclipse documentation indique ce qui suit sur le fichier .project:

Le but de ce fichier est de rendre l'auto-descriptif projet, donc qu'un projet qui est compressé ou libéré à un serveur peut être correctement recréé dans un autre espace de travail.

et:

Si un nouveau projet est créé à un endroit qui contient un fichier de description du projet existant, le contenu de ce fichier de description honorés que la description du 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 est non valide, la création du projet échouera.

Je suggère également d'utiliser Maven car cela vous permettra d'économiser beaucoup de problèmes avec la gestion de la dépendance 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 seulement besoin de partager le fichier pom.xml et .project dans git. Eclipse créera ensuite les fichiers .classpath, .settings/ automatiquement pour vous. Donc, évidemment, vous n'avez pas besoin de les partager. Si quelque chose change dans pom.xml, il suffit de lancer Maven -> "Mettre à jour la configuration du projet" et Maven -> "Mettre à jour les dépendances".

Sans Maven

Vous devrait partager le fichier .project et non le dossier .settings/. Vous pouvez envisager de partager .classpath mais cela peut conduire à des conflits comme expliqué ci-dessus. Je suggère de ne pas le partager non plus. Utilisez la méthode ci-dessous pour importer le projet:

Après avoir cloné le dépôt git vous pouvez simplement utiliser Importer -> Eclipse « un projet existant de l'espace de travail » honorera le fichier .project mais recrée les fichiers .classpath et .settings/. Après l'importation, vous devrez configurer manuellement le classpath à partir d'Eclipse (et chaque fois que votre équipe voudra 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 devez d'abord créer un nouveau projet avec l'assistant de projet, puis vous pouvez choisir l'importation "Général-> Système de fichiers", cela va copier 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 dépôt 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.

S'il vous plaît laissez un hommage si vous avez des suggestions à cette explication ou si vous n'êtes pas d'accord avec elle. J'espère que cela aide l'un ou l'autre.