1

そこで、git プロジェクトで構成ファイルを処理する方法を探していました。この件に関するいくつかの記事を読みましたが、そのすべてが 2 番目のローカル専用ファイルを提案しています。そして、それは私には正しくありません。

そこで、別の方法で物事を達成する方法を見つけるために、いくつかの git コマンドをいじりました。

これが可能であることがわかった方法は、次のようになります。

ファイル

key : valueこの例の構成は、ファイル内の単純なリストです。

local状態は、テンプレートの最新のプルされたバージョンです:

1 : 1
2 : 2
3 : 3

remote状態はリポジトリのバージョンです:

1 : 1
a : 2
3 : 3
4 : 4

このファイルには、1 つの新しいフィールド4と、変更されたフィールドがありますa。

最後に、working状態はアプリケーションが使用する構成ファイルです。localこれは、アプリケーションを実行するためのシークレット値で変更されたファイルのコピーです。このバージョンはリポジトリにプッシュしないでください。

1 : secret1
2 : secret2
3 : secret3

フロー

これが私が考えたワークフローです：

オンpull/ checkout:

  • working書き換えられないように、ファイルを別のファイルにバックアップします。
  • localとでマージを実行してremote、最後の構成テンプレートを取得します。
  • と を多少マージしlocalますsaved_working。

最後のマージは、既存のフィールド値を上書きしない限り、追加する新しいフィールドの表示をユーザーに提供する必要があります。

このような操作の例は次のとおりです。

最初のマージ:

-    2 : 2
+    a : 2
+    4 : 4

2回目のマージ:

1 : secret1
-    2 : secret2
+    a : 2
3 : secret3
+    4 : 4

そして今、アプリケーションを再び使用できるようになる前に、変更点が明確にわかります。

どう思いますか ？

4

2 に答える 2

0

リポジトリに構成ファイルを保存する必要がある理由をよく考えることをお勧めします。それがデフォルトのオプションセットである場合は、おそらくプロジェクトに統合する必要があります（バイナリにコンパイルされる可能性があります。IDKはプロジェクトです）。それがサンプルのオプション セットである場合は、作業ツリーで使用する必要はないので、プルするときは無視してください。とにかく、構成ファイルが見つからない場合にソフトウェアが使用できなくなることはありません。デフォルト値がいくつかあるはずなので、作業中の構成をレポのバージョンとマージする必要はありません。

以前は構成をリポジトリに保持していましたが、後で気が変わってこれらのコミットをすべて削除しました。構成は、ユーザー設定を参照する変更可能な状態です。コードリポジトリは、コードの履歴を保存するためのものです。これら 2 つの科目を混在させることは、私には悪い習慣のように思えます。

更新

古いバージョンから最近のバージョンへの構成のアップグレードをサポートしたくない場合は、想像できる方法が 1 つだけあります。

  • 構成テンプレートをレポに保存する
  • 実際の構成を以前のバージョンから最新のバージョンにアップグレードするツールをレポに追加します (小さなプログラムまたはより良いスクリプトである可能性があります)。
  • プル後のイベントで起動するようにこのツールを設定します。

そのため、開発者がリモート リポジトリからプルするたびに、構成ツールも更新されてから起動されます。リビジョンでコミットされたツールは、実際の構成ファイルを以前のバージョンから、このリビジョンで導入された最新のバージョンにアップグレードします。明らかに、ここでは (変更を追跡するために) プレーン テキスト ツールの方が適していますが、バイナリも機能します。

于 2015-07-21T09:04:14.637 に答える