실제로 많은 방법이 있으며 그 중 두 가지가 더 일반적으로 사용됩니다.

첫 번째는 구성 파일이 실제 콘텐츠를 제출하지 않고 템플릿 파일만 제출한다는 점입니다. Clone 후 각 개발자는 자신의 환경에 맞춰 설정파일을 완성하므로 자연스럽게 독립되게 된다(파일명 변경 필요, 유효한 설정파일 무시 필요).

구성 파일이 크고 구성 항목이 많은 경우 이 방법을 사용하면 모두가 불편해질 수 있습니다. 독립적으로 구성해야 하는 옵션을 별도의 파일로 추가로 나누고, 공유 구성 파일을 제출하고, 독립적으로 구성해야 하는 구성 파일을 템플릿화하면 문제를 줄일 수 있습니다. 그러나 구성을 사용할 때는 두 가지 유형의 파일을 병합해야 합니다. 이는 스크립트를 작성하여 수행할 수 있습니다. 또한 독립적인 구성 파일이 동일한 이름의 구성 항목을 덮어쓰도록 허용하여 구성을 사용자 정의할 수 있습니다.

두 번째 방법은 아이디어를 변경하고 구성 파일을 분할하거나 변경하지 않고 정상적으로 제출하는 것입니다. 민감한 정보가 나올 때마다 일반 텍스트를 작성하지 말고 대신 시스템 환경 변수를 사용할 수 있습니다. 각 개발자는 코드를 복제한 후 필요한 환경변수를 설정해야 하며(이 사항 자체는 별도로 관리할 수 있으며 특정 프로젝트와 관련이 없음), 프로젝트 자체의 운영은 이러한 환경변수의 존재 여부와 검증 유효성에 따라 달라집니다. , 등 잠깐만요.

첫 번째 방법은 다양한 오픈소스 프로젝트에서 더 일반적으로 사용되며, 두 번째 방법은 특정 임계값이 있으므로 고정된 팀 프로젝트에서 주로 사용됩니다. 개인적으로 저는 두 번째 방법을 선호하는데, 스크립트를 사용하면 간단하게 모든 것을 제어할 수 있고, 민감한 정보는 프로젝트와 독립적이어서 보안이 더 높기 때문입니다. (첫 번째 방법은 안타깝게도 항상 나쁜 놈들을 만나게 되거든요...) , 재사용성도 더 높습니다(예를 들어 여러 프로젝트에서 데이터베이스를 사용하는 경우 관련 환경 변수를 로컬에서 한 번만 설정하면 이 모든 프로젝트에서 사용할 수 있습니다).

무시 파일 목록에 추가됩니다 ---