Il est très courant d’avoir au moins un fichier de configuration dans un projet. Chaque fois que je partage un projet avec git
, j’ai le même problème avec:
De toute évidence, les configs doivent être ignorés pour empêcher les données spécifiques au développeur d’inonder le référentiel principal. Maintenant, il y a plusieurs façons dont j’avais l’habitude d’utiliser, chacune avec quelques défauts:
.gitignore
les fichiers de configuration
.git/info/exclude
ou set git update-index --assume-unchanged ...
dans le fichier
.gitignore
) _original
tout en ayant les vrais fichiers dans .gitignore
. Chaque développeur renomme alors les fichiers en vrais noms
Y a-t-il d’autres moyens, peut-être, de mieux gérer cela? Je pense que je manque quelque chose, du plugin au moins.
Les pilotes de filtre sont la manière “automatique” d’implémenter l’option 3, comme détaillé dans ” quand vous avez une clé secrète dans votre projet, comment pousser vers GitHub est possible? “:
Le script smudge
, à la caisse:
A partir de là, les développeurs peuvent apporter toutes sortes de modifications à ces fichiers de configuration.
Cela n’a pas d’importance, car le script clean
va, lors de la validation, restaurer le contenu de ce fichier à sa valeur d’origine (modèle). Aucune poussée accidentelle là-bas.
La façon dont nous l’avons fait sur le dernier projet sur lequel je travaillais était d’avoir un fichier de configuration maître chargé d’un fichier de configuration local si celui-ci était présent, ce qui pourrait écraser les parameters par défaut. en maître. Le fichier local a été ajouté à gitignore. De cette façon, tous les éléments courants peuvent être partagés et une configuration est toujours présente et chaque développeur peut modifier son local.
Dans les projets que j’ai été, nous avons une configuration par défaut et les développeurs ont leur propre configuration à un endroit particulier en dehors du contrôle de version (convention sur configuration) – les valeurs de ces derniers sont utilisées pour remplacer celles du premier.
Nous avons commencé à utiliser le chiffrement pour les détails sensibles dans la configuration: Gestion des mots de passe dans la configuration de production pour un déploiement automatisé
Dans le cas de git, vous pouvez regarder l’ git atsortingbutes filter atsortingbute
pour effectuer à la fois le remplacement des valeurs locales et le décryptage des valeurs sensibles de manière automatisée.
Vous pouvez aussi avoir des sous-modules qui ont le production.yml
et qui ont un access restreint au repo du sous-module.
Comme il m’a fallu un certain temps pour trouver une solution de travail avec les astuces de @VonC, voici un exemple complet de comment ignorer les mots de passe avec un filtre git clean dans un fichier d’en-tête Objective-C.
Supposons que vous avez un script de configuration par défaut nommé Config.h
contenant cette
// Change "12345" to your password #define kPass @"12345" #define kConstant 42
Créez un script hidepass.sh
correspondant aux lignes critiques et imprimez la ligne par défaut
#!/bin/sh awk '{ if (/#define kPass/) print "#define kPass @\"12345\""; else print $0; }' exit 0
Rendre le script exécutable et l’append au repository
Dites à git de filtrer votre fichier de configuration en ajoutant cette ligne à .gitatsortingbutes
(ajoutez également .gitatsortingbutes à votre repository)
Config.h filter=hidepass
Dites à git d’utiliser le script hidepass.sh
pour le filtre caché lors du nettoyage:
git config filter.hidepass.clean ./hidepass.sh
Ça y est, vous pouvez maintenant changer le mot de passe dans Config.h
mais git ne commettra pas ce changement car il remplace toujours cette ligne par la ligne par défaut lors de l’archivage.
Ceci est une solution rapide pour un mot de passe d’une ligne, vous pouvez devenir fou et par exemple terminer les lignes à ignorer avec une chaîne spéciale et vérifier les lignes avec cette chaîne.
Une chose à laquelle je peux penser est similaire à la méthode 2 et à la méthode 1 ci-dessus. Où vous avez un répertoire dans lequel vous stockez des éléments complexes propres au site, tels que des répertoires de fichiers de configuration, des fichiers téléchargés par l’utilisateur, etc.
Vous ne conservez que le fichier de configuration lui-même hors du contrôle de version, mais vous avez alors une copie factice nommée légèrement différemment de ce que le site utilise réellement et ce fichier contient des instructions détaillées sur les parameters de configuration et une copie renommée.
Par exemple, disons que vous avez un répertoire “site_profile”. Dans ce répertoire, vous créez un fichier appelé “README.settings.php” avec un répertoire “files” contenant les fichiers téléchargés par l’utilisateur (à la fois par les administrateurs et les utilisateurs frontaux). Tout cela est sous contrôle de version.
Cependant, le site exécutera ses parameters depuis “settings.php” qui n’existera pas ici. Mais si vous deviez renommer “README.settings.php” en “settings.php”, alors vous auriez le fichier de configuration dont vous avez besoin (après avoir bien sûr ajouté vos parameters personnalisés).
Cela vous permettra de dire aux autres développeurs ce dont ils ont besoin dans leur fichier de configuration tout en conservant votre propre fichier de configuration hors du mix. Il suffit de définir votre fichier de configuration pour qu’il soit ignoré ou de ne jamais faire de couverture pour ce répertoire et de le réduire.
C’est ce que nous faisons avec les sites Drupal où je travaille et ça marche vraiment bien.
Pour les deux cas, vous mentionnez:
informations sensibles (chaque développeur a des mots de passe différents, etc.)
Ecrivez vos scripts pour que ces fichiers sensibles soient stockés dans le répertoire de base du développeur plutôt que dans le répertoire du projet.
informations spécifiques à la tâche (lorsque le développeur travaille sur certaines tâches où il est nécessaire de modifier certains parameters)
Les parameters par défaut sont généralement archivés dans le référentiel. Lorsque vous préparez vos commits, vous pouvez facilement vérifier si vous avez modifié l’un de ces parameters et les annuler avant de les valider.
J’ai sauvegardé mes modifications de configuration locales sur un git stash. J’utilise git stash plutôt que pop, de sorte que je ne le retire jamais de la queue. De cette façon, je peux utiliser reset –hard chaque fois que j’en ai envie.
N’ayant aucune expérience avec Git, mais ayant traité les mêmes problèmes dans d’autres contextes (identifiants de connexion Hibernate dans une suite Spring JUnit ou scripts ANT), pour tout élément spécifique à l’utilisateur ou dépendant de l’environnement local d’un utilisateur:
, où jdbc.username
est une variable système (que vous pouvez définir dans Eclipse ). Les développeurs peuvent archiver ce qu’ils veulent, car la configuration est indépendante de l’utilisateur.
Beaucoup de bonnes options listées. Quelques autres options à mentionner:
apply-config /path/to/my_git1
, save-config /path/to/my_git1
qui copient ou sauvegardent fichiers de configuration du repository principal GIT.
Une autre option très courante, popularisée par The Twelve-Factor App , consiste à ne pas inclure de variables de configuration dans les fichiers, mais à les charger à partir de variables environnementales. De cette façon, les fichiers du référentiel ne nécessitent aucun traitement particulier.