Des métadonnées et de l'espace de travail
Je n'aurais jamais partager l' .metadata le dossier. En fait, sauf si vous avez une raison particulière je n'aurais même pas partager l'espace de travail dossier, mais plutôt partager chaque projet séparément avec git. De cette façon, l' .metadata le dossier sera toujours dans le dossier parent de votre dépôt git et vous n'avez pas à réfléchir pour savoir si vous avez besoin de l'ignorer, de toute façon:
|-- workspace/
| \-- .metadata/
| |-- yourProjectOne/
| | \-- .git/
| | |-- .project
| | |-- src/
| | |-- ...
| |-- yourProjectTwo/
| | \-- .git/
| | |-- .project/
| | |-- src/
| | |-- ...
Projet Spécifique
Vous devriez sans doute toujours de la part de l' .project le fichier et de ne jamais .settings/ fichiers. L' .classpath dépend de votre environnement, mais je ne voudrais pas suggérer de le partager, car il peut causer des conflits (par exemple, si un utilisateur utilise openjdk et l'autre utilise sun-jdk. L' .settings contient les préférences et les paramètres pour eclipse et change beaucoup de choses, donc il ne doit pas être partagé. Si vous avez correctement importer le projet après avoir cloné à partir de git ensuite vous pourrez également ne pas avoir des problèmes.
L' éclipse de la documentation stipule ce qui suit à propos de l' .project le fichier:
Le but de ce fichier est de faire de l'auto-description, de sorte
qu'un projet qui est fermée ou un serveur peut ê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, le contenu de la description du fichier
être reconnue comme la description du projet. Une exception est que le
nom du projet dans le fichier sera ignoré si il ne correspond pas au nom de
le projet en cours de création. Si la description du fichier sur le disque est
invalide, la création d'un projet échouera.
Je suggère également d'utiliser Maven que cela va vous faire économiser beaucoup de problèmes avec la gestion de la dépendance et de .classpath
Maven
La principale différence avec un projet Maven est que vous pouvez importer le projet Maven->"Existant Projets Maven" et donc seulement besoin de partager l'pom.xml et .project le fichier dans le dépôt git. Eclipse va alors créer l' .classpath, .settings/ fichiers automatiquement pour vous. Donc, évidemment, vous n'avez pas besoin de les partager. Si quelque chose change dans pom.xml il vous suffit d'exécuter Maven->"mise à Jour de la configuration du projet" et Maven->"mise à Jour des dépendances".
Sans Maven
Vous devez partager l' .project fichier et non l' .settings/ le dossier. Vous pouvez savoir à partager .classpath, mais il peut conduire à des conflits, comme expliqué ci-dessus. Je suggère de ne pas partager non plus. Utilisez la méthode ci-dessous pour importer le projet:
Après avoir cloné le dépôt git que vous pouvez simplement utiliser l'Import->"Projet Existant à partir de l'espace de travail" eclipse mettra à l'honneur l' .project le fichier mais recrée l' .classpath et .settings/ fichiers. Après l'importation, vous aurez besoin pour configurer le classpath à la main à partir d'Eclipse (et à chaque fois que votre équipe veut utiliser une autre bibliothèque).
Si vous ne partagez pas la .fichier de projet, alors il n'est pas possible d'importer le projet avec Eclipse. Vous aurez besoin de créer un nouveau projet avec l'assistant de projet tout d'abord, et puis vous pouvez choisir d'importer le "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, parce que cela signifie que vous ne pouvez pas cloner le dépôt git dans l'espace de travail, vous devez le copier à un autre endroit, puis l'importer à partir de là. Par conséquent, vous devriez toujours partager les .fichier de projet.
Merci de laisser un féliciter si vous avez des suggestions pour cette explication ou si vous n'êtes pas d'accord avec elle. J'espère que cette aide de l'une ou de l'autre.
