Il existe en réalité de nombreuses méthodes, dont deux sont les plus couramment utilisées.
La première est que le fichier de configuration ne soumet pas le contenu réel, mais soumet uniquement un fichier modèle. Après le clonage, chaque développeur complète le fichier de configuration en fonction de son propre environnement, afin qu'il devienne naturellement indépendant (le nom du fichier doit être modifié et le fichier de configuration valide doit être ignoré).
Si le fichier de configuration est volumineux et contient de nombreux éléments de configuration, cette méthode rendra tout le monde gênant. Vous pouvez diviser davantage les options qui doivent être configurées indépendamment dans un fichier séparé, soumettre le fichier de configuration partagé et modéliser le fichier de configuration qui doit être indépendant, ce qui peut éviter certains problèmes. Cependant, lors de l'utilisation de la configuration, vous devez fusionner les deux types de fichiers. Cela peut être fait en écrivant un script. De plus, des fichiers de configuration indépendants peuvent être autorisés à écraser les éléments de configuration portant le même nom, afin que la configuration puisse être personnalisée.
La deuxième méthode consiste à changer l'idée et à soumettre le fichier de configuration normalement sans le diviser ni le modifier. Chaque fois que vous rencontrez des informations sensibles, n'écrivez pas de texte brut. Vous pouvez plutôt utiliser des variables d'environnement système. Chaque développeur doit définir les variables d'environnement nécessaires après le clonage du code (cette question elle-même peut être gérée séparément et n'est pas liée au projet spécifique), et le fonctionnement du projet lui-même dépend de l'existence de ces variables d'environnement et de leur validité de vérification. , etc. attendez.
La première méthode est plus couramment utilisée dans divers projets open source ; la deuxième méthode a un certain seuil, elle est donc principalement utilisée dans les projets d'équipe fixe. Personnellement, je préfère la deuxième méthode, car je peux simplement utiliser des scripts pour tout contrôler, et les informations sensibles sont indépendantes du projet, donc la sécurité est plus élevée (dans la première méthode, malheureusement, je rencontre toujours des méchants...) , La réutilisabilité est également plus élevée (par exemple, si plusieurs projets utilisent la base de données, je n'ai besoin de définir qu'une seule fois les variables d'environnement pertinentes localement, et tous ces projets peuvent l'utiliser).
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Il existe en réalité de nombreuses méthodes, dont deux sont les plus couramment utilisées.
La première est que le fichier de configuration ne soumet pas le contenu réel, mais soumet uniquement un fichier modèle. Après le clonage, chaque développeur complète le fichier de configuration en fonction de son propre environnement, afin qu'il devienne naturellement indépendant (le nom du fichier doit être modifié et le fichier de configuration valide doit être ignoré).
Si le fichier de configuration est volumineux et contient de nombreux éléments de configuration, cette méthode rendra tout le monde gênant. Vous pouvez diviser davantage les options qui doivent être configurées indépendamment dans un fichier séparé, soumettre le fichier de configuration partagé et modéliser le fichier de configuration qui doit être indépendant, ce qui peut éviter certains problèmes. Cependant, lors de l'utilisation de la configuration, vous devez fusionner les deux types de fichiers. Cela peut être fait en écrivant un script. De plus, des fichiers de configuration indépendants peuvent être autorisés à écraser les éléments de configuration portant le même nom, afin que la configuration puisse être personnalisée.
La deuxième méthode consiste à changer l'idée et à soumettre le fichier de configuration normalement sans le diviser ni le modifier. Chaque fois que vous rencontrez des informations sensibles, n'écrivez pas de texte brut. Vous pouvez plutôt utiliser des variables d'environnement système. Chaque développeur doit définir les variables d'environnement nécessaires après le clonage du code (cette question elle-même peut être gérée séparément et n'est pas liée au projet spécifique), et le fonctionnement du projet lui-même dépend de l'existence de ces variables d'environnement et de leur validité de vérification. , etc. attendez.
La première méthode est plus couramment utilisée dans divers projets open source ; la deuxième méthode a un certain seuil, elle est donc principalement utilisée dans les projets d'équipe fixe. Personnellement, je préfère la deuxième méthode, car je peux simplement utiliser des scripts pour tout contrôler, et les informations sensibles sont indépendantes du projet, donc la sécurité est plus élevée (dans la première méthode, malheureusement, je rencontre toujours des méchants...) , La réutilisabilité est également plus élevée (par exemple, si plusieurs projets utilisent la base de données, je n'ai besoin de définir qu'une seule fois les variables d'environnement pertinentes localement, et tous ces projets peuvent l'utiliser).
Ceci est ajouté à la liste des fichiers ignorés ---