Que dois-je inclure dans mon référentiel de projets IDE

10

Je veux ajouter un projet qui dans ce cas est créé dans Netbeans mais cette question est générale pour la plupart des IDE. C'est simplement, que dois-je inclure dans mon référentiel. Par exemple, Netbeans crée un dossier nbproject, eclipse crée un dossier .settings, etc. dois-je les inclure dans mon référentiel, quels sont les avantages / inconvénients d'inclure ou de ne pas inclure les paramètres spécifiques au projet.

Dans ce cas, c'est un projet personnel, donc je n'imagine pas que d'autres personnes commenceront à travailler dessus, mais il serait bien d'ajouter le strict minimum de paramètres de projet pour que le projet lui-même soit facile à démarrer sur différentes machines.

programming-practices git project maintainability Daniel Figueroa
la source
Considérez des outils tels que maven avec son plugin eclipse (ou autre ide) pour configurer l'environnement approprié plutôt que d'inclure le vôtre.
@MichaelT Je suis vraiment désolé mais je ne suis pas vraiment d'accord.
Daniel Figueroa
L'utilisation d'un outil de génération et la configuration de l'outil de création de l'environnement pour l'idé vous permettent d'être assuré que la configuration est la même quelle que soit la plate-forme (ou l'idé). Même les développeurs solo ont plusieurs environnements (ide vs build). Cela simplifie la question à celle à laquelle il est répondu "ne pas archiver quoi que ce soit qui est spécifique à votre environnement, car ils sont générés du code." - le même raisonnement que vous ne consignez pas dans les classes .java générées par jaxb, mais plutôt les instructions (fichier build.xml ou .pom) sur la façon de les construire.
S'il est "original", il doit être sauvegardé. S'il change et que ceux-ci nécessitent un suivi et qu'il est d'origine, il doit être contrôlé par révision. Le hic - comment structurer votre référentiel afin que votre source reste votre source, tandis que vos configurations de chaîne d'outils ne polluent pas le référentiel source. La même chose s'applique aux ressources telles que les images, le son et la vidéo ....
mattnz

Réponses:

4

Cela dépend vraiment de quelles données il s'agit et doit être décidé au cas par cas, peut-être même pour des fichiers individuels. Jetez un œil au contenu de ces fichiers. Plus souvent qu'autrement, vous pouvez dire ce qu'ils signifient. Des trucs comme la position et la taille des fenêtres de l'IDE sont quelque chose que vous ne voulez pas dans le contrôle de code source.

Mais certains des fichiers de projet IDE sont des métadonnées de projet essentielles. Je ne connais pas bien Netbeans, mais pour eclipse, le fichier .project indique à l'EDI quel est le nom du projet, qu'il s'agit d'un projet Web Java, etc. et le fichier .classpath contient des informations sur les dossiers et bibliothèques sources. Certains fichiers du répertoire .settings peuvent être tout aussi importants, par exemple org.eclipse.core.resources.prefs contient des informations sur le codage à utiliser pour quels fichiers.

En tant que métadonnées de projet, ces éléments méritent largement d'être versionnés dans le contrôle de code source.

Certains IDE peuvent importer des métadonnées de projet à partir d'autres IDE. Il serait encore mieux de l'avoir sous une forme qui n'est pas liée à un IDE spécifique.

Pour Java, il y a une telle chose: Maven . Il impose des conventions strictes sur la structure du projet et vous permet de spécifier les métadonnées du projet (telles que les dépendances de bibliothèque) en un point (un fichier appelé pom.xml qui se trouve dans le répertoire principal du projet et, bien sûr, dans le contrôle de code source). Il existe des plugins qui créent ensuite des fichiers de projet IDE à partir de la configuration Maven, et d'autres qui peuvent automatiser le processus de construction du projet, ou faire à peu près n'importe quoi. Parfois, on a l'impression que cela rend les choses inutilement complexes et qu'il faut du temps pour apprendre, mais les avantages en valent généralement la peine.

Michael Borgwardt
la source
1
si je ne me trompe pas, Maven est indépendant de l'IDE. Dans l'affirmative, alors, car il contient les paramètres / métadonnées des projets, il devrait donc certainement être inclus dans le référentiel, mais pas les "fichiers de projet IDE" auxquels OP semble se référer spécifiquement.
Bleeding Fingers
@ hus787: mon point est que ces métadonnées sont très importantes pour être dans le repo, et bien que ce soit génial quand vous les avez sous une forme indépendante de l'IDE, quand ce n'est pas le cas, il vaut toujours mieux les avoir que de ne pas l'avoir.
Michael Borgwardt
2

Cela dépend vraiment du type d'informations que vous souhaitez avoir sur le référentiel. Si vous voulez tout savoir sur quels fichiers vous aviez ouvert et que vous éditiez au moment de la validation, et que vous êtes le seul à utiliser le référentiel, allez-y et validez tout, mais sachez que cela peut ne pas fonctionner sur une autre machine .

Si vous souhaitez pouvoir partager votre code avec d'autres personnes qui pourraient ne pas utiliser le même IDE, validez simplement le code lui-même sans implémentation spécifique au projet.

Si vous savez que tout le monde utilise le même IDE, vous pouvez probablement inclure tout ce qui n'est pas spécifique à l'ordinateur, c'est-à-dire tout fichier / dossier de configuration pour l'IDE lui-même, de cette façon, ils peuvent déjà avoir la possibilité d'importer le projet en tant que IDE l'attend.

Ampt
la source
2

Les artefacts qui aident votre développement et ne sont d'aucune utilité pour la construction / version ou le projet lui-même ne doivent pas être inclus. Le dépôt doit être propre et bien rangé et ne doit contenir que les éléments pertinents pour le projet et non votre environnement . Le repo ne doit pas tenir compte de vos habitudes. Et deuxièmement, cela vous gênera inutilement lorsque vous ferez quelque chose qui s'apparente à git status... mais bon, je n'ai jamais apporté de changements ... ahh ignorez cela.

Permettez-moi de donner un exemple plus pratique (je vais utiliser gitici comme outil):

Vous ne voudriez jamais qu'un sous-module (récursif) à l'intérieur de votre référentiel principal ait une substance spécifique à l'IDE (cela pourrait également interférer avec l'environnement du projet principal) car tout ce qui vous intéresse est le code qui a été écrit par quelqu'un d'autre (ou vous) et est d'utilisation à l'intérieur du projet en cours. Pas l'environnement dans lequel il a été développé. Vous ne voulez probablement pas non plus faire ça à quelqu'un d'autre.

Pour pouvoir utiliser votre paramètre sur une machine différente, je suggère de creuser à l'intérieur de votre IDE et de voir quel support il fournit pour de telles choses. Emacs a initet le serveur Emacs aussi. Ou vous pouvez créer votre macro ou script personnalisé ( .sh) qui effectue la configuration automatiquement.

Doigts saignants
la source
-1: pas du tout d'accord. Il peut s'agir d'informations très importantes et utiles, et votre dépôt devrait certainement inclure de telles informations.
Michael Borgwardt
@MichaelBorgwardt et si OP prévoit plus tard de passer à un autre IDE. Comment ces paramètres spécifiques au projet IDE seront-ils compris dans l'autre? Un exemple serait très apprécié.
Bleeding Fingers
Certains IDE peuvent importer des métadonnées de projet à partir d'autres IDE. Même s'ils ne le peuvent pas, ces fichiers sont généralement quelque peu lisibles par l'homme et il est préférable de ne pas les avoir.
Michael Borgwardt
Et que se passe-t-il si vous fubarez complètement votre espace de travail (ce qui m'est arrivé récemment) et que vous ne pouvez pas inverser les changements en rétablissant manuellement les choses comme vous les pensiez auparavant? Je me suis probablement économisé des heures parce que l'espace de travail a été archivé. Sans oublier que dans certains IDE, l'espace de travail inclura des choses comme des modèles de code qui seraient très difficiles à configurer manuellement à chaque fois.
Amy Blankenship
@AmyBlankenship c'est mon point c'est votre espace de travail comment pouvez-vous être sûr qu'il n'interfère pas avec les autres (ils tirent et tout d'un coup leur espace de travail est remplacé par le vôtre), il vaut mieux garder ces choses dans une branche locale séparée ou vous pouvez utiliser mercurial pour votre espace de travail spécifique au projet VC et git pour le projet VC. À propos des modèles de code, je pense que votre IDE n'est pas assez mature (ou n'a pas encore été exploré correctement) et si vous dites que les modèles sont spécifiques au projet, je suppose que vous devriez rechercher des modèles dans votre code.
Bleeding Fingers
1

Si c'est un projet personnel, je dis stocker les paramètres dans le contrôle de source. Personnellement, rien ne tue plus ma motivation pour un projet que de reconstituer un environnement de développement.

Quand plus de gens sont impliqués, je ne mets pas ces choses en contrôle de source. Dans mon équipe, nous utilisons un mélange d'IntelliJ, Sublime Text et Eclipse. Les fichiers IDE ajoutent simplement de l'encombrement et entraînent des commits dans ces fichiers provenant d'autres personnes pour un IDE que vous n'utilisez pas.

De plus, votre projet ne devrait de toute façon pas dépendre de l'IDE. Un serveur de build ne démarrera pas Eclipse pour compiler votre produit, il devrait donc déjà être sans IDE. Un point plus mineur: il élimine l'organisation personnelle au sein du projet. Par exemple, dans IntelliJ, j'aime utiliser de nombreux modules dans notre projet. Personne d'autre utilisant IntelliJ ne s'en inquiète car nous ne stockons pas les fichiers .iml (module).

Si votre équipe utilise le même IDE, c'est mieux, mais quelqu'un valide une mauvaise entrée .classpath car il a utilisé un chemin absolu. Désormais, tous ceux qui utilisent l'EDI s'en inquiètent.

Bien sûr, l'inconvénient est qu'il y a plus de configuration lorsque quelqu'un vérifie le projet. Je pense que ca vaut la peine. Nous utilisons Ivy pour la gestion des dépendances et avons des informations sur la configuration, les dépendances, etc. Malgré ce coût initial, je pense que cela vaut la peine de garder les paramètres IDE hors du contrôle des sources.

Kryptic
la source