There are actually many methods, two of which are more commonly used.
The first is that the configuration file does not submit the real content, but only submits a template file. After cloning, each developer completes the configuration file according to his or her own environment, so that it becomes independent naturally (the file name needs to be changed and the valid configuration file needs to be ignored).
If the configuration file is large and has many configuration items, this method will make everyone feel troublesome. You can further divide the options that need to be configured independently into a separate file, submit the shared configuration file, and template the configuration file that needs to be independent, which can save some trouble. However, when using configuration, you need to merge the two types of files - this can be done by writing a script. Furthermore, independent configuration files can be allowed to overwrite configuration items with the same name, so that the configuration can be customized.
The second method is to change the idea and submit the configuration file normally without splitting or modifying it. Whenever you encounter sensitive information, do not write clear text. You can use system environment variables instead. Each developer needs to set the necessary environment variables after cloning the code (this matter itself can be managed separately and is not related to the specific project), and the operation of the project itself depends on the existence of these environment variables and their verification validity, etc. wait.
The first method is more commonly used in various open source projects; the second method has a certain threshold, so it is mostly used in fixed team projects. Personally, I prefer the second method, because I can simply use scripts to control everything, and the sensitive information is independent of the project, so the security is higher (in the first method, unfortunately, I always encounter bad guys...), The reusability is also higher (for example, if multiple projects use the database, I only need to set the relevant environment variables locally once, and all these projects can use it).
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
There are actually many methods, two of which are more commonly used.
The first is that the configuration file does not submit the real content, but only submits a template file. After cloning, each developer completes the configuration file according to his or her own environment, so that it becomes independent naturally (the file name needs to be changed and the valid configuration file needs to be ignored).
If the configuration file is large and has many configuration items, this method will make everyone feel troublesome. You can further divide the options that need to be configured independently into a separate file, submit the shared configuration file, and template the configuration file that needs to be independent, which can save some trouble. However, when using configuration, you need to merge the two types of files - this can be done by writing a script. Furthermore, independent configuration files can be allowed to overwrite configuration items with the same name, so that the configuration can be customized.
The second method is to change the idea and submit the configuration file normally without splitting or modifying it. Whenever you encounter sensitive information, do not write clear text. You can use system environment variables instead. Each developer needs to set the necessary environment variables after cloning the code (this matter itself can be managed separately and is not related to the specific project), and the operation of the project itself depends on the existence of these environment variables and their verification validity, etc. wait.
The first method is more commonly used in various open source projects; the second method has a certain threshold, so it is mostly used in fixed team projects. Personally, I prefer the second method, because I can simply use scripts to control everything, and the sensitive information is independent of the project, so the security is higher (in the first method, unfortunately, I always encounter bad guys...), The reusability is also higher (for example, if multiple projects use the database, I only need to set the relevant environment variables locally once, and all these projects can use it).
This is added to the ignored file list ---