Dois-je garder mes fichiers de projet sous contrôle de version? [fermé]

Dois-je garder les fichiers de projet tels que .project, .classpath, .settings d'Eclipse, sous contrôle de version (par exemple Subversion, GitHub, CVS, Mercurial, etc.)?

Vous voulez garder dans le contrôle de version tous les fichiers de paramètres portables ,
c'est-à - dire:
Tout fichier qui n'a pas de chemin absolu.
Qui comprend:

• .projet,
• .classpath ( si aucun chemin absolu n'est utilisé , ce qui est possible avec l'utilisation de variables IDE ou de variables d'environnement utilisateur)
• Paramètres IDE (où je suis fortement en désaccord avec la réponse «acceptée»). Ces paramètres incluent souvent des règles d'analyse de code statique qui sont d'une importance vitale à appliquer de manière cohérente pour tout utilisateur chargeant ce projet dans son espace de travail.
• Les recommandations de paramètres spécifiques à l'IDE doivent être écrites dans un gros fichier README (et également versionnées bien sûr).

Règle de base pour moi:
vous devez pouvoir charger un projet dans un espace de travail et y avoir tout ce dont vous avez besoin pour le configurer correctement dans votre IDE et démarrer en quelques minutes.
Pas de documentation supplémentaire, de pages wiki à lire ou quoi d'autre.
Chargez-le, configurez-le, partez.

Fichiers .project et .classpath oui. Nous ne conservons cependant pas nos paramètres IDE dans le contrôle de version. Certains plugins ne font pas un bon travail de persistance des paramètres et nous avons constaté que certains paramètres n'étaient pas très portables d'une machine de développement à l'autre. Nous avons donc à la place une page Wiki qui met en évidence les étapes nécessaires à un développeur pour configurer son IDE.

Ce sont ce que je considère comme des fichiers générés et, en tant que tels, je ne les place jamais sous contrôle de version. Ils peuvent être différents d'une machine à l'autre et d'un développeur à l'autre, par exemple lorsque des utilisateurs ont installé différents plugins Eclipse.

Au lieu de cela, j'utilise un outil de construction (Maven) qui peut générer des versions initiales de ces fichiers lorsque vous effectuez une nouvelle extraction.

Je suis déchiré entre deux options ici.

D'une part, je pense que tout le monde devrait être libre d'utiliser l'ensemble des outils de développement avec lesquels il est le plus productif, à condition que tous les artefacts source soient stockés dans le contrôle de version et que le script de construction (disons ANT ou Maven) assure la conformité aux normes en spécifier exactement quel JDK utiliser, quelles versions de bibliothèques tierces dépendre, exécuter des vérifications de style (par exemple, checkstyle) et exécuter des tests unitaires, etc.

D'un autre côté, je pense que beaucoup de gens utilisent les mêmes outils (par exemple Eclipse) et il est souvent préférable de normaliser certaines choses au moment de la conception plutôt que de la construction - par exemple Checkstyle est beaucoup plus utile en tant que plugin Eclipse qu'en tant que une tâche ANT ou Maven - qu'il vaut mieux normaliser sur l'ensemble des outils de développement et un ensemble commun de plugins.

J'ai travaillé sur un projet où tout le monde utilisait exactement le même JDK, la même version de Maven, la même version d'Eclipse, le même ensemble de plugins Eclipse et les mêmes fichiers de configuration (ex: profils Checkstyle, règles de formateur de code etc.). Tous ces éléments ont été conservés dans le contrôle de code source - .project, .classpath et tout ce qui se trouve dans le dossier .settings. Cela a rendu la vie vraiment facile pendant les phases initiales du projet, lorsque les gens ajustaient continuellement les dépendances ou le processus de construction. Cela a également énormément aidé lors de l'ajout de nouveaux démarreurs au projet.

Dans l'ensemble, je pense que s'il n'y a pas trop de chances d'une guerre de religion, vous devriez standardiser sur l'ensemble de base des outils de développement et des plugins et assurer la conformité de la version dans vos scripts de construction (par exemple en spécifiant explicitement la version Java). ne pensez pas qu'il y ait beaucoup d'avantages à stocker le JDK et l'installation d'Eclipse dans le contrôle de code source. Tout le reste qui n'est pas un artefact dérivé - y compris vos fichiers de projet, votre configuration et vos préférences de plug-in (en particulier le formateur de code et les règles de style) - doit entrer dans le contrôle de code source.

PS Si vous utilisez Maven, il y a un argument pour dire que les fichiers .project et .classpath sont des artefacts dérivés. Cela n'est vrai que si vous les générez à chaque fois que vous effectuez une compilation, et si vous n'avez jamais eu à les modifier à la main (ou à les modifier par inadvertance en modifiant certaines préférences) après les avoir générés à partir du POM

Non, car je ne contrôle que les fichiers de contrôle de version nécessaires à la création du logiciel. En outre, les développeurs individuels peuvent avoir leurs propres paramètres spécifiques au projet.

Non, je suis un grand utilisateur de Maven et j'utilise le plugin Q for Eclipse qui crée et maintient à jour .project et .classpath. Pour d'autres choses telles que les paramètres des plugins, je garde généralement une page README ou Wiki à ce sujet.

De plus, ceux avec qui j'ai travaillé et qui préfèrent d'autres IDE utilisent simplement les plugins Maven pour générer les fichiers nécessaires pour garder leur IDE (et eux-mêmes) heureux.

Tout cela est une opinion, je suppose - mais les meilleures pratiques au fil des ans indiquent que les fichiers spécifiques à un IDE donné ne devraient pas être stockés dans le contrôle de code source, à moins que toute votre organisation ne soit normalisée sur un IDE et que vous n'ayez jamais l'intention de changer.

Dans tous les cas, vous ne voulez certainement pas que les paramètres utilisateur soient stockés - et .project peut contenir des paramètres vraiment spécifiques au développeur.

Je recommande d'utiliser quelque chose comme Maven ou Ant comme système de construction standardisé. Tout développeur peut obtenir un chemin de classe configuré dans son IDE en quelques secondes.

Oui, sauf pour le dossier .settings. La validation des autres fichiers fonctionne bien pour nous. Il y a une question similaire ici .

Bien que je sois généralement d'accord sur l'approche «ne pas utiliser de version des fichiers générés», nous avons des problèmes avec celle-ci et devons revenir en arrière.

Note: Je suis également intéressé par la réponse de VonC , en particulier sur le point "Get Eclipse up in minutes". Mais ce n'est pas décisif pour nous.

Notre contexte est Eclipse + Maven, utilisant le plug-in m2eclipse. Nous avons un environnement de développement commun, avec autant que possible des répertoires communs. Mais il arrive parfois que quelqu'un essaie un plug-in, ou modifie de petites choses dans la configuration, ou importe un deuxième espace de travail pour une branche différente ...

Notre problème est que la génération du .project se fait lors de l'importation d'un projet dans Eclipse, mais n'est pas mise à jour dans tous les cas par la suite . C'est triste, et probablement pas permanent car le plug-in m2eclipse s'améliorera, mais c'est vrai pour le moment. On finit donc par avoir des configurations différentes. Ce que nous avions aujourd'hui était que: plusieurs natures ont été ajoutées à de nombreux projets sur certaines machines, qui se sont alors comportées très différemment :-(

La seule solution que nous voyons est de versionner le fichier .project (pour éviter les risques, nous ferons de même pour .classpath et .settings). De cette façon, lorsqu'un développeur change son pom, les fichiers locaux sont mis à jour à l'aide de m2eclipse, tous sont validés ensemble et les autres développeurs verront tous les changements.

Remarque: dans notre cas, nous utilisons des noms de fichiers relatifs, nous n'avons donc aucun problème pour partager ces fichiers.

Donc, pour répondre à votre question, je dis oui, confiez ces fichiers.

J'ai aimé aussi:

• Réponse du vendeur riche

Il semble que ces fichiers de projet peuvent changer au fil du temps lorsque vous travaillez sur un projet, donc oui, je les place sous contrôle de version.

Oui. Tout sauf la sortie de construction.

Nous utilisons IntelliJ IDEA et gardons les versions '.sample' des fichiers projet (.ipr) et module (.iml) sous contrôle de version.

Le partage et la réutilisation sont quelque peu plus importants ici que la gestion des versions, à mon humble avis. Mais si vous allez partager ces configurations, quel meilleur endroit pour les mettre que le référentiel, juste à côté de tout le reste.

Quelques avantages des fichiers de projet partagés et versionnés:

• Vous pouvez consulter n'importe quelle balise / branche et commencer à travailler dessus rapidement
• Permet à un nouveau développeur de configurer plus facilement l'environnement de développement et de se mettre à niveau
• Cela adhère mieux à DRY, ce qui est toujours profondément satisfaisant. Avant cela, tous les développeurs devaient configurer ces éléments de temps en temps, en effectuant essentiellement un travail répété. Bien sûr, chacun avait ses propres moyens d'éviter de se répéter, mais en regardant l'équipe dans son ensemble, il y avait beaucoup d'efforts en double.

Notez que dans IDEA, ces fichiers contiennent des configurations telles que: quels sont les répertoires "source" et "source de test"; tout sur les dépendances externes (où se trouvent les fichiers JAR de la bibliothèque, ainsi que les sources ou javadocs associés); options de construction, etc. Ce sont des choses qui ne varient pas d'un développeur à l'autre (je ne suis pas du tout d'accord avec cela ). IDEA stocke plus de paramètres IDE personnels ailleurs, ainsi que toutes les configurations de plug-in. (Je ne connais pas très bien Eclipse; cela peut ou non être tout à fait différent.)

Je suis d'accord avec cette réponse qui dit:

Vous devez pouvoir charger un projet dans un espace de travail et y avoir tout ce dont vous avez besoin pour le configurer correctement dans votre IDE et démarrer en quelques minutes. [...] Chargez-le, configurez-le, partez.

Et nous l'avons comme ça, grâce aux fichiers de projet versionnés.