在使用git进行代码管理时候，有开发分支dev，线上分支pro。
在开发的时候，每个人会从dev分支上拉出自己的分支，进行开发，完成后合并到dev分支上面。
线上环境进行更新的时候，会从pro分支上面pull最近的代码，然后重启服务运行。
这里有一个问题，dev分支和pro分支，往往会存在几个文件不同情况，例如配置文件setting等等。在这种情况下应该如何处理比较合适？
如果git中不包含setting文件的话，如果配置文件需要更新的话，在线上环境就需要手动修改代码。
请问大家是如何做的？结合git做到自动化部署和回退？
多谢
高洛峰2017-05-02 09:27:01
프로덕션 환경과 비프로덕션 환경(예: 개발 환경, 테스트 환경 등)의 차이는 구성 외에도 일부 종속 리소스도 서로 다를 수 있습니다.
여기서 제가 사용하는 일반적인 방법은 프로덕션 환경과 기타 환경의 모든 구성을 해당 구성 파일(또는 여러 파일 config/dev.json, config/pro.json...)에 작성하는 것입니다. 구성 프로세서는 로컬 환경(git의 범위에 포함되며 초기화 모듈일 수 있음)이 무엇인지 읽고 구성 파일에서 해당 환경의 구성을 읽습니다. 하나의 구성 파일을 사용하면 다음과 유사합니다.
으아아아구성 프로세서는 현재 환경이 무엇인지 어떻게 알 수 있습니까? 여기에 环境标识가 있어야 합니다. 예를 들어 프로덕션 환경은 고정 IP에 배포됩니다. 단일 서버 단일 애플리케이션에 적합) 구성 파일의 프로덕션 환경 구성은 이 IP 아래에 기록됩니다. 구성 프로세서는 현재 실행 중인 환경의 IP를 얻은 후 구성 파일에 지정된 IP 모듈의 구성을 읽습니다. 🎜> 또 다른 방법은
을 사용하는 것입니다. 예를 들어 애플리케이션이 실행되는 모든 환경에는 /data/tag 텍스트 파일이 있습니다(프로젝트 디렉터리에 있을 수도 있지만 .gitignore에 포함됨). 파일은 git의 범위 내에 있지 않습니다. 标识文件 또는 pro로 작성된 한 줄만 있으므로 구성 프로세서는 이 파일을 읽어서 얻을 구성 파일의 부분을 알 수 있습니다. 가장 일반적인 방법은 dev과 같은 환경 변수를 사용한 다음 이 변수를 먼저 읽는 것입니다. 해당 환경 구성을 다시 읽어보세요.
export APP_ENV=production구성 서버
가 있어야 합니다. 각 서버의 애플리케이션 구성을 업데이트합니다. 이 구성 서버에서는 어떤 서버가 어떤 구성을 사용하는지 독립적으로 구성할 수 있습니다(일반적으로 요청자의 IP로 구성됨). 이런 방식으로 애플리케이션은 완전히 상태를 유지하지 않고
구성 파일이 전혀 필요하지 않으며
구성을 세밀하게 제어할 수 있습니다(예: 특정 서버의 요청 흐름을 늘리고 싶다), 그레이 스케일 릴리스 구현(일부 서버에 새 코드 배포)을 구현하는 것 외에도 현재 대부분의 인터넷 회사에서 채택하는 방법이 아닐까 생각합니다.
