github - git을 사용하여 코드를 관리하는데, 개발 브랜치와 온라인 브랜치가 서로 다른 파일을 갖고 있는데 어떻게 처리해야 할까요?

Question

코드 관리를 위해 git을 사용하면 개발 브랜치 dev와 온라인 브랜치 pro가 있습니다. 개발 중에는 모든 사람이 dev 브랜치에서 자신의 브랜치를 가져와서 개발하고 완료 후 dev 브랜치에 병합합니다. 온라인 환경이 업데이트되면 pro 브랜치에서 최신 코드를 가져오고...

高洛峰 · Answer

환경의 차이:

프로덕션 환경과 비프로덕션 환경(예: 개발 환경, 테스트 환경 등)의 차이는 구성 외에도 일부 종속 리소스도 서로 다를 수 있습니다.

구성 파일:

여기서 제가 사용하는 일반적인 방법은 프로덕션 환경과 기타 환경의 모든 구성을 해당 구성 파일(또는 여러 파일 config/dev.json, config/pro.json...)에 작성하는 것입니다. 구성 프로세서는 로컬 환경(git의 범위에 포함되며 초기화 모듈일 수 있음)이 무엇인지 읽고 구성 파일에서 해당 환경의 구성을 읽습니다. 하나의 구성 파일을 사용하면 다음과 유사합니다.

으아아아

환경표지

구성 프로세서는 현재 환경이 무엇인지 어떻게 알 수 있습니까? 여기에 环境标识가 있어야 합니다. 예를 들어 프로덕션 환경은 고정 IP에 배포됩니다. 단일 서버 단일 애플리케이션에 적합) 구성 파일의 프로덕션 환경 구성은 이 IP 아래에 기록됩니다. 구성 프로세서는 현재 실행 중인 환경의 IP를 얻은 후 구성 파일에 지정된 IP 모듈의 구성을 읽습니다. 🎜> 또 다른 방법은
을 사용하는 것입니다. 예를 들어 애플리케이션이 실행되는 모든 환경에는 /data/tag 텍스트 파일이 있습니다(프로젝트 디렉터리에 있을 수도 있지만 .gitignore에 포함됨). 파일은 git의 범위 내에 있지 않습니다. 标识文件 또는 pro로 작성된 한 줄만 있으므로 구성 프로세서는 이 파일을 읽어서 얻을 구성 파일의 부분을 알 수 있습니다. 가장 일반적인 방법은 dev과 같은 환경 변수를 사용한 다음 이 변수를 먼저 읽는 것입니다. 해당 환경 구성을 다시 읽어보세요.
export APP_ENV=production구성 서버

나중에는 대부분의 애플리케이션이 분산 방식으로 배포됩니다. 즉, 동일한 애플리케이션이 20개 이상의 서버에 배포될 수 있습니다. 이때

구성 서버

가 있어야 합니다. 각 서버의 애플리케이션 구성을 업데이트합니다. 이 구성 서버에서는 어떤 서버가 어떤 구성을 사용하는지 독립적으로 구성할 수 있습니다(일반적으로 요청자의 IP로 구성됨). 이런 방식으로 애플리케이션은 완전히 상태를 유지하지 않고
구성 파일이 전혀 필요하지 않으며
구성을 세밀하게 제어할 수 있습니다(예: 특정 서버의 요청 흐름을 늘리고 싶다), 그레이 스케일 릴리스 구현(일부 서버에 새 코드 배포)을 구현하는 것 외에도 현재 대부분의 인터넷 회사에서 채택하는 방법이 아닐까 생각합니다.

世界只因有你 · Answer

무시 파일을 설정하고 무시 파일에 다양한 구성 매개변수를 저장합니다.