프로젝트 구성 파일을 처리하는 가장 쉬운 방법은 무엇입니까?

모든 프로젝트에 하나 이상의 구성 파일이있는 것은 매우 일반적입니다. 와 프로젝트를 공유 할 때마다 git다음과 같은 문제가 발생합니다.

• 민감한 정보 (개발자마다 다른 DB 비밀번호 등)
• 작업 별 정보 (개발자가 일부 설정을 변경해야하는 특정 작업을 수행하는 경우)

개발자 특정 데이터가 주 저장소에 넘치지 않도록하려면 구성을 무시해야합니다. 이제 사용하던 여러 가지 방법이 있으며 각각 몇 가지 결함이 있습니다.

• .gitignore 구성 파일
  • 가장 기본적인 방법
  • 개발자가 repo를 복제 할 때 구성 파일이 누락되어 구성이 다시 생성 된 위치를 찾아야합니다.
• 구성 파일은 무시되지 않습니다. 여기에는 더미 정보가 포함되어 있으며 각 개발자는 추적을 해제하여 자신의 위치에 .git/info/exclude넣거나 git update-index --assume-unchanged ...파일에 설정 합니다.
  • 저장소를 복제하는 모든 사람이 파일을 사용할 수 있습니다.
  • 처음으로 git을 사용하는 사람들을 혼동시킬 수있는 고급 기술이 포함되어 있습니다.
  • 누군가 우연히 구성 파일을 커밋하면 사람들이 가져 오기 / 가져 오기를 허용하지 않습니다 (제외 항목은에서와 같은 방식으로 작동하지 않음 .gitignore).
• 예를 들어 접미사가 붙은 구성 파일을 배포 _original하고 실제 파일은 .gitignore. 그런 다음 각 개발자는 파일 이름을 실제 이름으로 바꿉니다.
  • 저장소를 복제하는 모든 사람이 파일을 사용할 수 있습니다.
  • 응용 프로그램 전체에서 모든 구성을 검색하고 이름을 변경해야합니다.

이것을 처리하는 다른 더 나은 방법이 있습니까? 나는 내가 뭔가, 적어도 일부 플러그인을 놓치고 있다고 생각합니다.

필터 드라이버 는 " 프로젝트에 비밀 키가있을 때 어떻게 GitHub로 푸시 할 수 있습니까? "에 자세히 설명 된대로 옵션 3을 구현하는 "자동"방법입니다 .

smudge체크 아웃에 스크립트 의지 :

• 수정할 올바른 구성 파일 감지
• 필요한 정보를 가져오고 ( Git 저장소 외부에 가장 잘 보관 됨 ) 템플릿 값을 실제 값으로 대체합니다.

여기에서 개발자는 해당 구성 파일을 원하는대로 수정할 수 있습니다. 스크립트는 커밋시 해당 파일의 내용을 원래 (템플릿) 값으로 복원
하기 때문에 문제가되지 않습니다 clean. 우연히 밀지 않습니다.

내가 작업 한 마지막 프로젝트에서 수행 한 방법은 사용자 로컬 구성 파일이있는 경우 사용자 로컬 구성 파일을로드하는 마스터 구성 파일을 갖는 것이 었는데, 지정하면 마스터에 설정된 기본값을 덮어 쓸 수 있고 존재하지 않는 경우 자체 구성 정보를 선언 할 수 있습니다. 마스터. 로컬 파일이 gitignore에 추가되었습니다. 이렇게하면 모든 공통 항목을 모두 공유 할 수 있고 일부 구성은 항상 존재하며 각 개발자는 로컬을 수정할 수 있습니다.

@VonC의 힌트로 작동하는 솔루션을 찾는 데 시간이 걸리기 때문에 Objective-C 헤더 파일에서 git clean 필터로 암호를 무시하는 방법에 대한 전체 예제가 있습니다.

1. Config.h이것을 포함 하는 기본 구성 스크립트가 있다고 가정하십시오.

   // Change "12345" to your password
   #define kPass @"12345"
   #define kConstant 42
   

2. hidepass.sh임계 줄과 일치 하는 스크립트 를 만들고 대신 기본 줄을 인쇄합니다.

   #!/bin/sh
   awk '{ if (/#define kPass/) print "#define kPass @\"12345\""; else print $0; }'
   exit 0
   

3. 스크립트를 실행 가능하게 만들고 저장소에 추가하십시오.

4. 이 줄을 추가하여 git에게 구성 파일을 필터링 .gitattributes하도록 지시하십시오 (또한 .gitattributes를 저장소에 추가하십시오).

   Config.h filter=hidepass
   

5. 청소하는 동안 git에게 hidepass 필터에 hidepass.sh대한 스크립트를 사용하도록 지시하십시오 .

   git config filter.hidepass.clean ./hidepass.sh
   

이제 비밀번호를 변경할 수 Config.h있지만 git은 항상 해당 행을 체크인시 기본 행으로 대체하기 때문에이 변경 사항을 커밋하지 않습니다.

이것은 한 줄 암호에 대한 빠른 솔루션입니다. 당신은 미쳐 버릴 수 있습니다. 예를 들어 무시할 줄을 특수 문자열로 끝내고 해당 문자열이있는 줄을 확인합니다.

내가 해본 프로젝트에서는 기본 구성이 있으며 개발자는 버전 제어 (구성에 대한 규칙) 외부의 특정 위치에 자신의 구성을 가지고 있습니다. 후자의 값은 전자의 값을 재정의하는 데 사용됩니다.

구성의 중요한 세부 정보에 암호화를 사용하기 시작했습니다. 자동화 된 배포를 위해 프로덕션 구성에서 암호 처리

git의 경우 git attributes filter attribute자동화 된 방식으로 로컬 값의 교체와 민감한 값의 암호 해독을 모두 수행 할 수 있습니다 .

production.yml및 하위 모듈 저장소에 대한 액세스가 제한된 하위 모듈을 가질 수도 있습니다 .

내가 생각할 수있는 한 가지는 위의 방법 2와 방법 1과 유사합니다. 구성 파일, 사용자 업로드 파일 등의 디렉토리와 같이 사이트에 고유 한 복잡한 것을 저장하는 디렉토리가 있습니다.

구성 파일 자체 만 버전 제어에서 제외되지만 사이트에서 실제로 사용하는 것과 약간 다른 이름의 더미 복사본이 있으며이 파일에는 구성 매개 변수에 대한 자세한 지침과 이름이 바뀐 복사본을 만드는 방법이 포함되어 있습니다.

예를 들어 "site_profile"디렉토리가 있다고 가정합니다. 이 디렉토리에서 "README.settings.php"라는 파일을 만들고 사용자가 업로드 한 파일 (관리자 및 프런트 엔드 사용자 모두)이 포함 된 "files"디렉토리를 만듭니다. 이 모든 것은 버전 관리하에 있습니다.

그러나 사이트는 여기에 존재하지 않는 "settings.php"에서 설정을 실행합니다. 그러나 "README.settings.php"의 이름을 "settings.php"로 바꾸려면 필요한 구성 파일을 갖게됩니다 (물론 사용자 지정 설정을 입력 한 후).

이를 통해 다른 개발자에게 자신의 구성 파일을 믹스에서 제외하고 구성 파일에서 필요한 것을 알릴 수 있습니다. 구성 파일을 무시하도록 설정하거나 해당 디렉토리 이하에 대한 일괄 커밋을 수행하지 마십시오.

내가 일하는 Drupal 사이트에서 우리가하는 일은 정말 잘 작동합니다.

두 가지 경우에 대해 언급합니다.

• 민감한 정보 (개발자마다 다른 DB 비밀번호 등)

  이러한 민감한 파일이 프로젝트 디렉토리가 아닌 개발자의 홈 디렉토리에 저장되도록 스크립트를 작성하십시오.

• 작업 별 정보 (개발자가 일부 설정을 변경해야하는 특정 작업을 수행하는 경우)

  일반적으로 기본 설정을 저장소에 체크인 한 다음 커밋을 준비 할 때 해당 설정을 수정했는지 쉽게 확인하고 커밋하기 전에 되돌릴 수 있습니다.

내 로컬 구성 변경 사항을 git stash에 저장했습니다. 팝 대신 git stash apply를 사용하므로 숨김 대기열에서 제거하지 않습니다. 그런 식으로 내가 원할 때마다 reset --hard를 사용할 수 있습니다.

Git에 대한 경험은 없지만 다른 컨텍스트 (Spring JUnit 스위트의 Hibernate 로그인 크레드 또는 ANT 스크립트)에서 동일한 문제를 처리했습니다.

1. 이러한 종속성과 스크립트를 실행하도록 로컬 환경을 구성하는 방법을 나열하는 README가 있습니다.
2. conf의 이러한 종속성을 시스템 속성에 대한 호출 또는 외부 값을 가져 오는 프레임 워크 방식으로 대체하십시오. 예를 들어 ANT 스크립트에서 문자열을로 바꿀 수 있습니다 <sysproperty key="jdbc.username" value="${jdbc.username}"/>. 여기서는 jdbc.username시스템 변수입니다 (Eclipse에서 설정할 수 있음).

conf는 사용자에 구애받지 않기 때문에 개발자는 원하는대로 체크인 할 수 있습니다.

많은 좋은 옵션이 나열되어 있습니다. 언급 할 몇 가지 추가 옵션 :

• 모든 구성을 .gitignore에 추가하십시오. 그런 다음 구성 파일 만 있는 별도의 git 프로젝트가 있습니다. 유사한 몇 가지 스크립트를 만들어,이 GIT # 2에서 (. 완전히 다른 폴더에이 GIT # 2 유지) apply-config /path/to/my_git1, save-config /path/to/my_git1에 복사하거나 주요 GIT의 REPO에 대한 구성 파일 저장.
  • 서브 모듈을 사용하는 것보다 이것을 선호합니다. 대규모 팀에서 하위 모듈로 작업하는 것이 번거 롭다는 것을 알았습니다.
  • 그런 다음 구성을 추적하거나 프로덕션 설정, 디버그 설정,보다 최적화 된 설정 등과 같은 항목에 대해 여러 GIT 저장소를 사용할 수 있습니다.
  • 모두가 이해하는 하나의 도구 (GIT)를 사용합니다.
• 나는 홈 폴더에서 DB 연결 정보와 같은 민감한 정보를 찾는 아이디어를 좋아합니다. (@avh에서 언급)
• devOps의 경우 배포 및 설정 자동화를 위해 Ansible / Salt / Chef / Puppet과 같은 것을 고려할 수 있습니다.

The Twelve-Factor App 에서 널리 사용되는 또 다른 매우 일반적인 옵션 은 구성 변수를 파일에 하드 코딩하지 않고 환경 변수에서로드하는 것입니다. 이렇게하면 저장소의 파일에 특별한 처리가 필요하지 않습니다.