プロジェクトにはsuper.configファイルがあります。 多くの異なるプロジェクト設定が含まれています。 たとえば、サードパーティのサービスとの対話の構成やログのレベル。 バージョン管理システム-git。
問題は何ですか：
- このファイルには「一般」設定が含まれているため、バージョン管理下にある必要があります。 さて、ファイル構造自体は貴重です。
- 各開発者は、必要に応じてロギングのレベルを変更しますが、これらの変更がコミットに陥るのを望まず、さらに統合リポジトリに陥ることを望みません。
- このファイルでは、一般的な設定が定期的に変更されており、開発者はそれらを受け取り（ pull ）、公開（ commit ）したい
可能な解決策：
- アプリケーションのソースコードとその構成を個別に保存します。 しかし、人生は痛みであり、常にできるとは限りません。 この理由は異なります：技術的なものから（
無能な人々）管理者へ。 - 設定のダウンロードを試してください。 たとえば、バージョン管理下でdefault.super.configを保存し、 super.configを除外します 。 アプリケーションは最初にdefault.super.configからプロパティをロードし、次に、存在する場合はsuper.configからプロパティをロードする必要があります。 さらに、後者の値はデフォルトの値と重複しています。
- ローカル設定の変更をインデックスに追加しないでください。
長所：
- シンプル。
- 設定への変更をコミットする必要がある場合、これは断片的に行われます（ git add -p ）。
短所：
- git addは実行しません。
- いくつかの変更を常に「迫ります」。 開発者は毎回それらを分析し、すべてがコミットされているかどうかを確認します。
- 別の設定を使用したブランチへの切り替え（ checkout ）は、 -mスイッチまたはstashを介してのみ可能です（ -fスイッチは作業コピーの変更を強制終了します）。
- 構成の変更をプルすると、エラーが発生します。 変更を受け取る前に、ローカルの変更を棚に置く必要があります。
-
バージョン管理から構成を除外します。
動作しません。 バージョン管理から除外できるのは、追跡されていないファイルのみです。
- 構成ファイルが変更されないことをgitに確認してください。 方法：
git update-index --assume-unchanged super.conf
長所：
- git add。 追加しすぎないでください。
- 「純粋」ステータス。
短所：
- Gitは、別の設定でブランチに切り替えたり、設定の変更を受信またはコミットすることはできません。 同時に、コンソールのメッセージは誤解を招く可能性があります： git statusは「コミットするものがありません。作業ディレクトリはクリーンです」 、 git pullは「次のファイルへのローカル変更は...」 を書き込みます 。
この状況を解決するには、リバースコマンドgit update-index --no-assume-unchanged super.confで git eyesを開く必要があります。 とにかく、その後、棚を使用する必要があります。 - git ls-files -vを使用して、 gitが目を閉じているものを確認できます。 grep -e "^ [hsmrck]" （そうではありませんが、それでも明らかです）。
私は何をしますか：
設定がめったに変更されない場合、 -assume-unchangedは適切なソリューションのように見えます。 そうでなければ、私は単に変更に注意を払っていなかっただろう。
一般に、設定を個別に保存する必要があります。