3

私の状況は、かなり典型的だと思います。私は、バージョン管理に git を使用して、他の何人かと (若い) プロジェクトに取り組んでいます。私たちのプロジェクトは、いくつかの異なる構成ファイルにまたがる特定のパスとキーのローカル構成を必要とする Web アプリです。これを処理する良い方法は、これらの構成ファイルのテンプレート バージョンを作成し、リポジトリで追跡することであると考えましたが、個々の構成ファイルは追跡しません (推奨、例:こことここ)。設定ファイルを誤ってコミットしないようにするために、設定ファイルを gitignore リストに追加しました。

しかし、私たちはプロジェクトの開始時にこれに気づきませんでした。1 人がプロジェクトを開始し、他のメンバーが参加した後でした。そのため、設定ファイルの 1 つがコミット履歴の早い段階で追跡されました。私たちの解決策:もちろん、インデックスから削除してください!

しかし、これは厄介な問題を引き起こします。 簡単なシナリオを次に示します。構成ファイルが追跡されるブランチがあります。

git init # new repository
echo 'file a' > a.txt
git add a.txt
git commit -m 'initial commit'

次に、これが問題であることに気付いたので、それを修正するために新しいブランチを作成します。新しいブランチで、リポジトリ インデックスから構成ファイルを削除します (そして、追跡したいテンプレート バージョンを追加します)。次に、元のファイルを gitignore します。

git checkout -b testbranch
cp a.txt a.template.txt
echo 'a.txt' > .gitignore  # ignore a.txt
git add .gitignore
git add a.template.txt
git rm --cached a.txt
git commit -m 'make template file for a'
ls  # shows that a.txt and a.template.txt are still in working tree
git status  # shows that working directory is clean

もちろん、構成ファイルに重要な更新を加えます。

echo 'super-critical config setting' >> a.txt

次に、ブランチを切り替え、マージし、BOOM !!

構成ファイルは実際にはなくなっており、行った変更はどのブランチでも追跡されません。

git checkout master
ls # shows a.txt, not a.template.txt
git checkout testbranch
ls # a.txt is gone!!

git checkout master
git merge testbranch master  # a.txt is gone forever!!

gitignorea.txtファイルを使用すると、インデックスからファイルを削除してからブランチを切り替えると上書きまたは削除されるという警告がマスクされます。gitignoring 以外の上記の手順を実行すると、a.txt移動または削除せずに testbranch から切り替えることはできませんa.txt。それを別の追跡されていないファイル ( a-copy.txt) に移動し、master をチェックアウトしてから testbranch を再度チェックアウトすると、要求どおりにそれa.txtがなくなっていることがわかりますが、a-copy.txtまだそこにあります。

それは私が（多分）理解している部分です。私が理解できないことは次のとおりです。他に何がこのシステムに問題を引き起こす可能性がありますか? git は個々のファイルではなくコンテンツのチャンクを追跡するため、特定のファイル (名前) がリポジトリで追跡されない (特にインデックスから削除されない) 場合でも、非常に重要な構成設定が失われる可能性がある方法はありますか? )? リポジトリ内の追跡されていない (gitignored) データが決して黙って削除されないことを絶対に確実にする方法はありますか?

そして、記録のために、私が遭遇したローカル構成を処理するための他のオプションを次に示します。最初の 3 つは、忘却/エラーが発生しやすいハックのように見えます。次の 2 つは、他のファイルをローカルで構成する必要があり、失われる可能性があります。最後のものはやり過ぎのように見えますが、そうではないかもしれません。これらのいずれかが構成ファイルを処理する最良の方法であると確信している場合は、その理由を説明してください。あなたがもっと良いことを知っていれば、それは素晴らしいことです！

  1. git stash
  2. git update-index --assume-unchanged
  3. ローカル設定用の個別のブランチ、個別の開発者ごとにプライベート
  4. git 属性フィルター ドライバー(スマッジ/クリーン スクリプト)
  5. 「展開」スクリプト、ここでも開発者ごとに個別かつ非公開
  6. 各開発者は、メインのコード リポジトリとは完全に独立して、構成ファイルを追跡するための個別のリポジトリを維持します。
4

1 に答える 1

1

機密情報の一般的な経験則は次のとおりです。

git に機密情報を入れないでください

あなたがどのような方針に従っているにせよ (機密事項のための特別なブランチや " git update-index --assume-unchanged" 戦術など)、すべきでないことをプッシュするリスクは常にあります。

Slaven Rezicはシンボリックリンク について言及しています:

ln -s config.yaml.$username config.yaml

ただし、そのためには、すべてのユーザーが適切な構成ファイルと機密データをその中に持つ必要があります。
そのファイルが新しい進化を取得する必要がある場合、各ユーザーの独自の構成 (sylinked) ファイルにそれらを伝播するのは困難です。

もう 1 つのオプションは、コンテンツ フィルタ ドライバを使用することです。

コンテンツ フィルタ

チェックアウト時に次のようになります。

  • テンプレート構成ファイルを読み取る
  • git リポジトリ外の参照から機密データにアクセスします (ここで独自のポリシーを定義します)。
  • 値のプレースホルダーが正しいデータに置き換えられた (プライベート、「バージョン管理されていない」など) 構成ファイルを生成します。
于 2013-08-12T07:10:42.017 に答える