Sebenarnya terdapat banyak kaedah, dua daripadanya lebih biasa digunakan.
Pertama ialah fail konfigurasi tidak menyerahkan kandungan sebenar, tetapi hanya menyerahkan fail templat. Selepas pengklonan, setiap pembangun melengkapkan fail konfigurasi mengikut persekitarannya sendiri, supaya ia menjadi bebas secara semula jadi (nama fail perlu ditukar dan fail konfigurasi yang sah perlu diabaikan).
Jika fail konfigurasi besar dan mempunyai banyak item konfigurasi, kaedah ini akan membuatkan semua orang berasa menyusahkan. Anda boleh membahagikan lagi pilihan yang perlu dikonfigurasikan secara bebas kepada fail yang berasingan, serahkan fail konfigurasi yang dikongsi dan templat fail konfigurasi yang perlu bebas, yang boleh menjimatkan beberapa masalah. Walau bagaimanapun, apabila menggunakan konfigurasi, anda perlu menggabungkan dua jenis fail - ini boleh dilakukan dengan menulis skrip. Tambahan pula, fail konfigurasi bebas boleh dibenarkan untuk menulis ganti item konfigurasi dengan nama yang sama, supaya konfigurasi boleh disesuaikan.
Kaedah kedua ialah menukar idea dan menyerahkan fail konfigurasi seperti biasa tanpa membelah atau mengubahnya. Setiap kali anda menemui maklumat sensitif, jangan tulis teks biasa Anda boleh menggunakan pembolehubah persekitaran sistem. Setiap pembangun perlu menetapkan pembolehubah persekitaran yang diperlukan selepas mengklonkan kod (perkara ini sendiri boleh diuruskan secara berasingan dan tidak berkaitan dengan projek tertentu), dan operasi projek itu sendiri bergantung pada kewujudan pembolehubah persekitaran ini dan kesahihan pengesahannya , dsb. tunggu.
Kaedah pertama lebih biasa digunakan dalam pelbagai projek sumber terbuka; kaedah kedua mempunyai ambang tertentu, jadi ia kebanyakannya digunakan dalam projek pasukan tetap. Secara peribadi, saya lebih suka kaedah kedua, kerana saya hanya boleh menggunakan skrip untuk mengawal segala-galanya, dan maklumat sensitif adalah bebas daripada projek, jadi keselamatan lebih tinggi (dalam kaedah pertama, malangnya, saya selalu menghadapi orang jahat...) , Kebolehgunaan semula juga lebih tinggi (contohnya, jika berbilang projek menggunakan pangkalan data, saya hanya perlu menetapkan pembolehubah persekitaran yang berkaitan secara setempat sekali, dan semua projek ini boleh menggunakannya).
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Sebenarnya terdapat banyak kaedah, dua daripadanya lebih biasa digunakan.
Pertama ialah fail konfigurasi tidak menyerahkan kandungan sebenar, tetapi hanya menyerahkan fail templat. Selepas pengklonan, setiap pembangun melengkapkan fail konfigurasi mengikut persekitarannya sendiri, supaya ia menjadi bebas secara semula jadi (nama fail perlu ditukar dan fail konfigurasi yang sah perlu diabaikan).
Jika fail konfigurasi besar dan mempunyai banyak item konfigurasi, kaedah ini akan membuatkan semua orang berasa menyusahkan. Anda boleh membahagikan lagi pilihan yang perlu dikonfigurasikan secara bebas kepada fail yang berasingan, serahkan fail konfigurasi yang dikongsi dan templat fail konfigurasi yang perlu bebas, yang boleh menjimatkan beberapa masalah. Walau bagaimanapun, apabila menggunakan konfigurasi, anda perlu menggabungkan dua jenis fail - ini boleh dilakukan dengan menulis skrip. Tambahan pula, fail konfigurasi bebas boleh dibenarkan untuk menulis ganti item konfigurasi dengan nama yang sama, supaya konfigurasi boleh disesuaikan.
Kaedah kedua ialah menukar idea dan menyerahkan fail konfigurasi seperti biasa tanpa membelah atau mengubahnya. Setiap kali anda menemui maklumat sensitif, jangan tulis teks biasa Anda boleh menggunakan pembolehubah persekitaran sistem. Setiap pembangun perlu menetapkan pembolehubah persekitaran yang diperlukan selepas mengklonkan kod (perkara ini sendiri boleh diuruskan secara berasingan dan tidak berkaitan dengan projek tertentu), dan operasi projek itu sendiri bergantung pada kewujudan pembolehubah persekitaran ini dan kesahihan pengesahannya , dsb. tunggu.
Kaedah pertama lebih biasa digunakan dalam pelbagai projek sumber terbuka; kaedah kedua mempunyai ambang tertentu, jadi ia kebanyakannya digunakan dalam projek pasukan tetap. Secara peribadi, saya lebih suka kaedah kedua, kerana saya hanya boleh menggunakan skrip untuk mengawal segala-galanya, dan maklumat sensitif adalah bebas daripada projek, jadi keselamatan lebih tinggi (dalam kaedah pertama, malangnya, saya selalu menghadapi orang jahat...) , Kebolehgunaan semula juga lebih tinggi (contohnya, jika berbilang projek menggunakan pangkalan data, saya hanya perlu menetapkan pembolehubah persekitaran yang berkaitan secara setempat sekali, dan semua projek ini boleh menggunakannya).
Ini ditambahkan pada senarai fail yang diabaikan ---