Qu’est-ce qui ne devrait PAS être sous contrôle de source?

Tout ce qui est généré. Binaire, bytecode, code / documents générés à partir de XML.

De mes commentateurs, exclure:

• Tout ce qui est généré par la construction, y compris les documentations de code (doxygen, javadoc, pydoc, etc.)

Mais inclure:

• Bibliothèques tierces que vous n’avez pas la source pour OU ne construisent pas.

FWIW, dans mon travail pour un très gros projet, nous avons sous ClearCase:

• Tout le code original
• Qt source ET debug / release construit
• Spécifications (terriblement obsolètes)

Nous n’avons pas de modules construits pour notre logiciel. Un binary complet est dissortingbué toutes les deux semaines avec les dernières mises à jour.

Fichiers spécifiques au système d’exploitation, générés par leurs navigateurs de fichiers tels que Thumbs.db et .DS_Store

Certains autres fichiers / dossiers typiques de Visual Studio sont

 *.cachefile *.backup _UpgradeReport_Files 

Mon modèle global d’ignorance de tortue ressemble par exemple à ceci

 bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files 

les fichiers créés ne doivent pas être archivés

Comme Corey D a déclaré que tout ce qui est généré, en particulier tout ce qui est généré par le processus de construction et l’environnement de développement, est un bon candidat. Par exemple:

• Binaires et installateurs
• Bytecode et archives
• Documents générés à partir de XML et du code
• Code généré par des modèles et des générateurs de code
• Fichiers de parameters IDE
• Fichiers de sauvegarde générés par votre IDE ou votre éditeur

Certaines exceptions à ce qui précède pourraient être:

• Images et vidéo
• Bibliothèques tierces
• Fichiers de parameters IDE spécifiques à l’équipe

Prenez des bibliothèques tierces, si vous avez besoin d’expédier ou que votre construction dépend d’une bibliothèque tierce, il ne serait pas déraisonnable de la placer sous contrôle de source, surtout si vous n’en avez pas la source. Considérons également que certains systèmes de contrôle de code source ne sont pas très efficaces pour stocker des objects blobs binarys et que vous ne pourrez probablement pas tirer parti des outils de différenciation de systèmes pour ces fichiers.

Paul fait également un excellent commentaire sur les fichiers générés et vous devriez vérifier sa réponse :

Fondamentalement, si vous ne pouvez pas raisonnablement attendre d’un développeur qu’il ait la version exacte de l’outil exact dont il a besoin, il y a des raisons de placer les fichiers générés dans le contrôle de version.

Tout cela étant dit, vous devrez considérer ce que vous placez sous le contrôle des sources au cas par cas. Définir une liste difficile de quoi et quoi ne pas mettre sous ne fonctionnera que pour certains et probablement pour si longtemps. Et bien sûr, plus vous ajoutez de fichiers au contrôle des sources, plus la mise à jour de votre copie de travail sera longue.

Tout ce qui peut être généré par l’EDI, le processus de construction ou le processus exécutable binary.

Je voudrais aborder le problème d’une manière différente; Quelles sont les choses à inclure dans le contrôle des sources? Vous ne devez contrôler que les fichiers qui:

• (besoin de l’historique des révisions OU sont créés en dehors de votre build mais font partie de la construction, de l’installation ou du support) ET
• ne peut être généré par le processus de construction que vous contrôlez ET
• sont communs à tous les utilisateurs qui créent le produit (pas de configuration utilisateur)

La liste comprend des choses comme:

• fichiers source
• fichiers de fabrication, de projet et de solution
• autres fichiers de configuration d’outils de génération (non liés à l’utilisateur)
• Bibliothèques tierces
• des fichiers pré-construits qui vont sur les médias comme les PDF et les documents
• Documentation
• images, vidéos, sons
• fichiers de description comme WSDL, XSL

Parfois, une sortie de construction peut être une entrée de génération. Par exemple, un fichier renommé d’obfuscation peut être une sortie et une entrée pour conserver le même schéma de renommage. Dans ce cas, utilisez le fichier archivé comme entrée de génération et placez-le dans un fichier différent. Après la construction, extrayez le fichier d’entrée et copiez-y le fichier de sortie et archivez-le.

Le problème avec l’utilisation d’une liste d’exclusion est que vous ne saurez jamais toutes les bonnes exclusions et que vous finirez par contrôler une source qui ne devrait pas être contrôlée par la source.

Une exception:

4 ou 5 réponses différentes ont indiqué que les fichiers générés ne devraient pas être contrôlés par les sources. Ce n’est pas tout à fait vrai.

Les fichiers générés par des outils spécialisés peuvent appartenir au contrôle de source, en particulier si des versions particulières de ces outils sont nécessaires.

Exemples:

• parsingurs générés par bison / yacc / antlr,
• des fichiers autotools tels que configure ou Makefile.in, créés par autoconf, automake, libtool, etc.
• fichiers de traduction ou de localisation,
• les fichiers peuvent être générés par des outils coûteux, et il peut être moins coûteux de les installer uniquement sur quelques machines.

Fondamentalement, si vous ne pouvez pas raisonnablement attendre d’un développeur qu’il ait la version exacte de l’outil exact dont il a besoin, il y a des raisons de placer les fichiers générés dans le contrôle de version.

Cette exception est discutée par les gars de svn dans leurs bonnes pratiques .

Fichiers temporaires des éditeurs.

 .*.sw? *~ 

etc.

desktop.ini est un autre fichier Windows que j’ai vu pénétrer

Fichiers de configuration contenant des mots de passe ou toute autre information sensible.

Les fichiers de configuration réels tels que web.config dans asp.net car les gens peuvent avoir des parameters différents. Habituellement, je gère cela en ayant un fichier web.config.template sur SVN. Les gens l’obtiennent, apportent les modifications souhaitées et la renomment web.config.

Mis à part cela et ce que vous avez dit, faites attention aux fichiers sensibles contenant des mots de passe (par exemple).

Évitez tous les fichiers gênants générés par Windows (thumb) ou Mac OS (.ds_store)

*.bak produit par WinMerge.

aditionellement:

Visual Studio

• * .ncb

La meilleure façon de penser à cela est la suivante:

Imaginez que vous avez un nouvel ordinateur acheté en magasin. Vous installez le système d’exploitation et les mises à jour; vous installez tous vos outils de développement, y compris le client de contrôle de code source; vous créez un répertoire vide pour être la racine de vos sources locales; vous effectuez un “get latest” ou tout ce que votre système de contrôle de la source appelle pour récupérer des copies propres de la version que vous souhaitez construire; vous exécutez ensuite la construction (récupérée à partir du contrôle de code source) et tout se construit.

Ce processus de reflection vous explique pourquoi certains fichiers doivent être sous contrôle de code source: tous ceux nécessaires pour que la compilation fonctionne sur un système propre. Cela inclut les fichiers .designer.cs, les sorties des modèles T4 et tout autre artefact que la génération ne créera pas.

Fichiers temporaires, config pour autre chose que le développement global et les informations sensibles

Quelle que soit la langue:

• fichiers de cache
• généralement, les fichiers importés ne doivent pas non plus (comme les images téléchargées par les utilisateurs, sur une application Web)
• fichiers temporaires ; même ceux générés par votre système d’exploitation (comme thumbs.db sous Windows) ou IDE
• fichiers de configuration avec mots de passe? Dépend de qui a access au référentiel

Et pour ceux qui ne le savent pas: svn:ignore is great!

Les choses qui ne vont pas dans le contrôle des sources sont disponibles en 3 classes

1. Des choses totalement indépendantes du projet (évidemment)
2. Les choses qui peuvent être trouvées sur le support d’installation et qui ne sont jamais modifiées (par exemple: API tierces).
3. Les choses qui peuvent être générées mécaniquement, via votre processus de construction, à partir de choses qui sont en contrôle de source (ou de choses en classe 2).

Si vous avez un environnement d’exécution pour votre code (par exemple, des bibliothèques de dépendances, des versions spécifiques du compilateur, etc.), ne placez pas les packages dans le contrôle de source. Mon approche est brutale mais efficace. Je mets en place un fichier Make, dont le rôle est de télécharger (via wget) les éléments, de les décompresser et de créer mon environnement d’exécution.

J’ai un fichier .c particulier qui ne va pas dans le contrôle de code source.

La règle n’est rien dans le contrôle de code source généré lors du processus de génération.

La seule exception connue est si un outil nécessite une version plus ancienne de lui-même (problème de bootstrap). Dans ce cas, vous aurez besoin d’une copie bootstrap bien connue dans le contrôle de source pour pouvoir créer à partir de données vides.

Sortir sur une twig ici, mais je crois que si vous utilisez des listes de tâches dans Visual Studio, elles sont conservées dans le fichier .suo. Ce n’est peut-être pas une raison de les garder sous contrôle de code source, mais c’est une raison de garder une sauvegarde quelque part, juste au cas où …

Beaucoup de temps s’est écoulé depuis que cette question a été posée, et je pense que beaucoup de réponses, bien que pertinentes, n’ont pas de détails .gitignore sur .gitignore par langue ou par niveau IDE.

Github est sorti avec une liste très utile de fichiers .gitignore collaborés avec la communauté pour toutes sortes de projets et d’EDI.

Voici un lien vers ce repository git: https://github.com/github/gitignore

Pour répondre à la question, voici les exemples relatifs à:

• C # -> voir Visual Studio
• Visual Studio
• Java
• Éclipse
• Python

Il existe également des fichiers .gitignore spécifiques au système d’ .gitignore . Suivant:

• les fenêtres
• OS X
• Linux

Donc, en supposant que vous utilisez Windows et que vous utilisez Eclipse , vous pouvez simplement concaténer Eclipse.gitignore et Windows.gitignore dans un fichier .gitignore dans le répertoire de niveau supérieur de votre projet. Des trucs très chouettes.

N’oubliez pas d’append le .gitignore à votre repo et validez-le!

Les chances sont, votre IDE gère déjà cela pour vous. Visual Studio fait quand même.

Et pour les fichiers .gitignore , si vous voyez des fichiers ou des motifs manquants dans un .gitignore particulier, vous pouvez ouvrir un PR sur ce fichier avec la modification proposée. Jetez un coup d’œil sur les trackers de demande de validation et d’extension pour des idées.

J’utilise toujours http://www.gitignore.io pour générer un fichier .ignore approprié.

Opinion: si vous en avez besoin, tout peut être contrôlé à la source, à moins que cela ne génère des frais supplémentaires importants, tels que des blobs changeants ou volumineux.

Les fichiers binarys tiers, difficiles à générer (en termes de temps), génèrent des fichiers pour accélérer votre processus de déploiement, tout va bien.

L’objective principal du contrôle de source est de faire correspondre un état de système cohérent à un numéro de révision. Si cela était possible, je bloquerais l’univers entier avec les outils de construction de code et le système d’exploitation cible.