3

私たちのプロジェクトには、データベースへの接続文字列といくつかのアプリケーション設定を保持する構成ファイルがあります。

...
<setting name="ConnectionString"><value>Server=prodServer;Database=myDataBase;</value></setting>
<setting name="AnotherSetting1"><value>Lorem</value></setting>
<setting name="AnotherSetting2"><value>Ipsum</value></setting>
<setting name="AnotherSetting3"><value>dolor </value></setting>
...

私の開発中、私は常にConnectionString値をローカルデータベースに変更します。これにより、git はファイルを「変更済み」としてマークします。

次のことを行うオプションについて読みました。

git update-index --assume-unchanged app.config

ただし、これは、ファイルに他の変更を加えると (たとえば、AnotherSetting1を変更する)、git もそれを無視することを意味します。

ファイルの特定の変更を無視するようにgitに指示する方法はありますが、他の変更が発生した場合は変更済みとしてマークする方法はありますか? または、この問題に対する別の同様の解決策はありますか?

構成ファイル自体のアーキテクチャに変更を加えることができないと仮定してください。ローカルのみのソリューションが必要です。

4

4 に答える 4

6

フィルターはこのようなもののために作られています。あなたのレポで、

cat >.git/info/saved-connection <<EOD
<setting name="ConnectionString"><value>Server=prodServer;Database=myDataBase;</value></setting>
EOD

cat >.git/info/my-connection <<EOD
<setting name="ConnectionString"><value>Server=myprivateserver;Database=myDataBase;</value></setting>
EOD

git config filter.use-my-connection.smudge 'sed -f ".git/info/use-my-connection.smudge"'
git config filter.use-my-connection.clean  'sed -f ".git/info/use-my-connection.clean"'

cat >.git/info/use-my-connection.smudge    <<EOD
/^<setting name="ConnectionString">/ {
     w .git/info/saved-connection
     r .git/info/my-connection
     d
}
EOD

cat >.git/info/use-my-connection.clean     <<EOD
/^<setting name="ConnectionString">/ {
     w .git/info/my-connection
     r .git/info/saved-connection
     d
}
EOD

echo >> .git/info/attributes     path/to/app.config filter=use-my-connection
于 2013-04-10T21:05:12.030 に答える
1

これがどのように行われるかについて、いくつかの提案をさせてください。

インデックスに変更を追加するときgit add -p app.configは、ファイル内の変更の一部を使用して手動でスキップできます。コミットする前にインデックスに変更を追加しないと、これらの変更はコミットされません。これは一種の「ローカルのみ」のソリューションです。git statusしかし、レポートで常にファイルが変更されているのを見るのは本当につまらないかもしれません。

他のすべての提案では、アーキテクチャの変更が必要になる可能性があるため、「ローカルのみ」のソリューションとは見なされません。とにかく、レビューする価値があると思います。

すべての変更の主なアイデアは、.gitignoreローカル システム固有の設定を含むローカル ファイルを追加することです。ここでは、わずかに異なるソリューションをいくつか使用しました。

  • すべてのローカル システム固有の値を含むキーと値のペアを持つプロパティ ファイルを持つことができます。このファイルは手動で更新する必要があります。次に、アプリケーションで使用され、アプリケーション構成にマージされます。詳細は、使用しているツールによって異なります。しかし、これによって大きな問題が発生することはないと思いますが、おそらくアプリケーションの変更が必要になるでしょう。
  • app-original.configファイルを git リポジトリに、app.configファイルをgit無視リストに入れることができます。ファイルはapp.configファイルから手動で作成する必要がありapp-original.configます。

これらすべてのソリューションで本当につまらないのは、構成ファイルの構造が変更されたときに手作業が必要になることです。たとえば、構成ファイルを更新するたびに、新しいプロパティが導入されているかどうかを確認し、ローカル プロパティ ファイルを更新する必要があります。同様に、いくつかのアプリケーションの変更のためにローカル ファイルを更新するときは、構成ファイルに関連する変更をコミットすることを覚えておく必要があります (ローカル ファイルは にあることに注意してください.gitignore)。

于 2013-03-01T07:02:03.653 に答える
1

gitそのような施設はないと思います。また、ファイル バージョンの一部を管理し、その他の部分を管理しないという、ファイルを管理する提案された方法は、app.config私には適切ではありません。

あなたの状況ではapp.config、2 つのファイルから生成されるように配置する方法を探します。設定はConnectionStringユーザーが作成した (ビルド) 構成ファイルに配置され、他の部分は何らかのテンプレート ファイルに配置されます (概念的に言えば)。ユーザーが作成した構成ファイルをファイルに追加でき.gitignoreます。テンプレート ファイルは によって制御されgitます。app.configビルド構成ファイルの設定をテンプレート ファイルに適用して、ファイルをビルドする方法が必要です。

これをすべて実装する方法を説明するための開発設定に関する背景情報が不足しています。makeまたはant類似のものを使用している場合、これはapp.config、ファイルが存在しない場合、またはビルド構成ファイルまたはテンプレート ファイルが変更された場合にファイルが作成されることを確認するための単純な依存関係とルールになります。app.configまた、テンプレート ファイルからファイルを生成する方法の自然な選択は、ビルド環境とファイルの性質によって異なります。app.configファイル。2 行以上のテキストの場合、シェル スクリプトを使用して特定のテンプレート ファイルを簡単に展開することもできます (${VARIABLE} 構造を展開するための数行の行ですが、ファイルに ${VARIABLE} を含める必要がある場合はさらに複雑になります)。記号またはバックティックまたはバックスラッシュなど)。より複雑な拡張を使用できますeruby、eperlまたは同様のもの (おそらくPHP)。設定を変更する必要があるときはいつでも、app.configファイルを手動で生成することもできます。しかし、これはすべて、それ以上の文脈がなければ、やや役に立たない憶測です.

于 2013-03-01T04:25:50.110 に答える
0

この問題の良い解決策を見つけたと思います。

私が言ったように、私のプロジェクトには、その構成ファイル内に接続文字列を（誤って）保存する構成ファイルがあります。

変更されたバージョンの構成で作業できるようにしたいのですが、ファイルを常に「変更された」ファイルリストに入れたり、すべての変更を完全に無視したりする必要はありません。

これが私がすることです

サーバーからクローンを作成すると、ログ グラフは次のようになります。

A---B---C master

私の開発はすべて別のブランチ「開発」で行われます。なので分岐します。次に、構成ファイルを変更し、接続文字列を変更してコミットします。

A---B---C master, origin/master
         \
          X development

次に、マスターをチェックアウトし、「--nocommit」フラグを使用して変更をマージします。次に、マージ コミットで、構成の変更を元に戻してコミットします。実際には、これらの変更がマージされ、再度マージする必要がないことを Git に通知するためだけの空のコミットを作成しました。

A---B---C---D master, origin/master
         \ /
          X development

X で新機能の開発を続けているので、変更を master に安全にマージできます。Git は、最後のマージ以降の新しい変更のみをマージしようとします。

A---B---C---D---E---F master, origin/master
         \ /       /
          X---Y---Z development

したがって、上記の例では、「Y」と「Z」の変更のみがマージされます。

私はそれを試してみましたが、うまく機能しているようです。ただし、マスター ブランチに切り替えるたびに、正しくない接続文字列を含む構成が作成されることになりますが、ほとんどの開発は「開発」ブランチで行われるため、大きな問題にはなりません。私に発行します。

私の解決策に問題がある場合は、コメントでお知らせください。

アップデート

これに関する問題は、構成ファイルが「マスター」で何らかの方法で変更され、「マスター」の変更を「開発」ブランチにマージすると、構成ファイルが警告なしに上書きされることです。

于 2013-03-13T14:29:28.687 に答える