在使用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 のスコープに含まれており、初期化モジュールである場合もあります)、構成ファイルが 1 つしかない場合は、構成ファイル内の対応する環境の構成を読み取ります。 、これは次のようなものです:
リーリー設定プロセッサはどのようにして現在の環境を認識するのでしょうか? ここに 环境标识,比较直接粗放的可以是IP地址,比如生产环境是部署在某个固定IP(适合单服单应用情况)上,配置文件的生产环境配置就写在这个IP下面,那配置处理器取到当前运行环境的IP后,去读取配置文件指定IP模块的配置.
还有一种方式是在使用一个标识文件,比如应用运行的所有的环境下都有一个/data/tag文本文件(也可以在项目目录下,但是用.gitignore包含),这个文件不在git范围内就行,其中就只有一行,写了pro或dev,这样配置处理器通过读这个文件就知道取配置文件中的哪部分配置了.
最常用的方式还有环境变量,比如export APP_ENV=production があり、最初にこの変数を読み取り、次に環境の対応する設定を読み取る必要があります。
この構成サーバーでは、どのサーバーがどの構成を使用するかを個別に構成できます (通常は、リクエスターの IP で構成されます)。各アプリケーションは、起動時に構成サーバーにアクセスして独自の構成を要求します。 このようにして、アプリケーションは完全にステートレスになるために、設定ファイルはまったく必要ありません
、設定を好きなだけ細かく制御できます（たとえば、リクエストを増やしたい）特定のサーバーのトラフィックを削減し、グレースケールリリース（一部のサーバーに新しいコードをデプロイする）を実装するのが、現在ほとんどのインターネット企業で採用されている方法ではないかと思います
