バージョン管理と個人設定ファイル
このプロジェクトでは、ユーザー固有の構成ファイルを使用します。このファイルはユーザーごとに異なるため、現在バージョン管理されていません。問題は、開発者が構成を必要とする新しいモジュールを追加したり、既存のモジュールの名前を変更したりすると、プライベート構成ファイルが更新されないため、他の開発者がエラーを受け取ることです。
この問題を解決するために、2つの構成ファイルで作業することを考えました。バージョン管理され、新しいモジュールを追加する各開発者によって定期的に更新されるデフォルト/グローバル構成ファイルと、公開されないプライベート構成ファイルです。バージョン管理のバージョンであり、ユーザー固有の変更のみが含まれます。
ただし、これはまだアドホックソリューションのようです。
より良い解決策を提案できますか？
専門家は何をしますか？
あなたはすでにここでいくつかの良い答えを得ましたが、それらのほとんどはあなたの問題の根本的な原因を見逃しています：あなたのユーザー設定ファイルは単にユーザー固有の情報以上のものを含んでいるようです、それらはまたどこかでバージョン管理されている（おそらく冗長な）情報を含んでいます、おそらくモジュール名のような異なるファイルにあります。
ここで私は2つの可能な解決策を考えることができます：
その情報を厳密に分離するようにしてください。たとえば、ユーザー設定でモジュール名を使用しないでください。 ID番号（GUIDなど）を使用してモジュールを参照し、モジュールに割り当てられた後にこれらのID番号が変更されないようにします。もちろん、おそらくこれには、ユーザー設定ファイルが現在持っているかもしれないシンプルさの一部を失うという欠点があります。プレーンテキストエディターを使用する代わりに、おそらく構成ファイルを編集するためのGUIツールを作成する必要があります。
設定ファイルのフォーマットにバージョン番号を付け、モジュール名のようなものが変更されたときはいつでも、それらに新しいバージョン番号を割り当てます。次に、バージョン番号をチェックするアップグレードスクリプトを提供できます。設定ファイルが最新でない場合は、ファイル内で見つかったすべてのモジュール名を変更し、後でバージョン番号を増やします。これは自動化できるので、アップグレードのプロセスがチームメイトの日常業務を妨げることはありません。
編集：あなたの投稿をもう一度読んだ後、新しいモジュールが追加されただけで名前が変更されていない限り、あなたの想定した解決策は合理的だと思います。上記で書いたものは、後でモジュール名または既存のモジュールの構成の構造を変更できるようにします。しかし、あなたがそれを必要としないなら、私は最も単純な解決策に固執します。
それは合理的な解決策です。
新しい構成要素の初期値を指定する方法が必要です。これらはどこかに保存する必要があり、グローバルな読み取り専用の構成ファイルが当然の選択です。
次に、各ユーザーが個人設定を変更するときに、これらの変更をローカルコピーに書き込みます。
変更された値を上書きするには、コードで最初にグローバル構成とユーザー固有の構成を読み取る必要があります。これは、ローカルの設定を読み取ってから、設定されていない設定を見つけようとするよりもはるかに簡単なので、グローバル設定ファイルから読み取る必要があります。
ストレージにXMLのようなものを使用する場合は、設定を削除する場合の処理について心配する必要はありません。ユーザーがファイルのコピーから要求されることはありません。保存時にファイルを再作成すると、変更後にアプリケーションが初めて使用されるときに削除されます。
やや興味深い解決策があります。主にPHP開発者なので、PHPで記述された自動化タスクを作成できるPhingを使用しているため、通常のsvn更新ではなく、 "phing update"はsvn updateを呼び出し、次にconfigsを適切な変数、たとえばconfigに置き換えます。
$db_user = "${test.db_user}";
そのため、構成ファイルはすべて、その興味深い構文でバージョン管理されています。次に、特定のインスタンス用のアドホックのバージョン管理されていない構成ファイルを生成します。このようにして、ユーザー固有のファイルを変更し、他の作業コピー全体に変更を反映させることができます。
プログラムは、値が構成ファイルで見つからない場合のコードのデフォルト設定を持っている必要があります。このようにすると、新しいものが追加されても壊れることはなく、アップグレードパスがよりスムーズになり、ユーザーが構成ファイルをめちゃくちゃにした場合のフォールバックが可能になります。
別のより複雑な例は、プログラムの起動時またはその他の重要なポイントで、初期化モジュールを使用して構成ファイルを開き、不足しているデフォルトを追加しますが、これはかなり重いようです。
バージョン番号を個人用構成ファイルに入れます（構成ファイル形式のバージョン番号）。
個人用構成ファイルを処理するコードにバージョン番号を確認させ、古い場合は更新手順を実行します。そのため、基本的に、既存の構成ファイルを壊す変更を行う人は誰でも、構成ファイル形式のバージョン番号を上げ、前のバージョンの構成ファイルを更新する手順（セクションの名前を変更するなど）を記述して、再度保存する必要があります。それら。
とにかく、エンドユーザーにはこのようなプロセスが必要になるので、開発者の生活を楽にするためにこのプロセスを使用することもできます。
通常は、デフォルト値が設定された構成ファイルをリポジトリにチェックインすることで確認しました。これらは、例として、テストサーバーで必要な値である可能性があります。次に、開発者がファイルをチェックアウトすると、すべての値が含まれます。新しいフィールドが追加された場合、またはフィールドが削除された場合、これはマージで処理されます。開発者は、ターゲットサーバーに必要な値をチェックインし、個人的な開発環境用のフィールドに対する他の変更はチェックインしません。
マージが正しく行われるように注意しますが、私にはかなり安全に思えます。
ここでは、設定のブロックを作成します。これは、Zendで次のように実行できます。
[production]
key1: parameter1
key2: parameter2
[testing: production]
key1: parameter2
key3: parameter4
つまり、テストは本番環境を継承し、key3で拡張します。各開発者が行う必要があるのは、自分の環境を設定することだけです（この場合、テストまたは本番）。
このような構成の問題を処理する Config というツールを作成しました。ここでは、1つのマスター構成ファイルを作成（またはインポート）します。次に、ローカルと呼ばれる環境を作成します。ローカル環境で、ユーザーごとに1つのインスタンスである複数のインスタンスを作成します。新しい構成エントリの追加やモジュール名の変更など、ボード全体で共通の変更を行う必要がある場合は、変更を加えるだけで、ボード全体に適用されます。インスタンス/ユーザーを変更する場合は、その構成値を変数にしてから、変数を変更します。この変更はインスタンス/ユーザーにのみ適用されます。これらはすべてバージョン管理下にあります。プッシュまたはプルを介して構成ファイルをデプロイします。 pullオプションはgit pullに似ていますが、特定のインスタンス/ユーザー向けです。
Configは、ユーザー間での構成の比較、検索、タグ付け、検証、ワークフローなどの追加機能を提供します。それはSaaSなので、まだクラウドの準備ができていない人には向いていませんが、オンプレミス計画があります。
これは、投稿に基づく便利なソリューションです： パスワードをソース管理に保持する
要約すると、戦略は「構成ファイルの暗号化されたバージョンをソース管理に保持し、ユーザーがそのデータを暗号化および復号化できる手段を提供する」ことです。
- ダミーのcomfigファイルを作成し、.gitignoreします。
- 構成ファイルを暗号化および復号化できるメイクファイルを作成します
- Makefileと暗号化された構成ファイルをリポジトリに保存します
- Makefileはパスワードと、作成者にパスワードを問い合わせる方法を尋ねます。
- プロジェクトをビルドするときに、メイクファイルが実行されない場合は、console.error（ "Config file [conf/settings.json] missing！
make decrypt_conf？ - 設定ファイルが最新であることを確認するためのチェックが記述されています。