it-swarm-ja.com

安全なデータでGitリポジトリを使用する

同僚と私は、ワークステーションで保存が許可されていないデータを使用するプロジェクトに一緒に取り組みたいと考えています(会社のサーバーに保存できます。できますopenワークステーションでそれ)。このデータを使用するコードを記述して共有する必要があります。これには、データのクリーンアップや、クリーンアップされたバージョンのデータの保存(会社のサーバー上)が含まれます。これらのクリーンアップされたバージョンは、バージョン管理下にある必要があります。 Gitを使用しています。

Gitリポジトリをどのように設定する必要がありますか?会社のサーバーにベアリモートリポジトリを配置した場合、そのリポジトリにクローンを作成すると、データは作業ツリーに保存されるため、ワークステーションに保存されます。リモートリポジトリを使用してコードをバージョン管理するだけの場合、データはバージョン管理されません。会社のサーバー上にベア以外のGitリポジトリを作成し、両方がその中で直接機能する場合、バージョン管理のメリットは実際には得られません。

どんな考えにも感謝します。

1
Tom

小さな注意点:データがリモートの場所に保存されていて、ワークステーションにopenデータを保存している場合、もちろんすべての操作がで行われない限り、一時的であっても、データは効果的にそこに保存されます。 -メモリ。 (それでも、法的な解釈によっては、RAMにのみ保存されている場合でも、これはマシンに保存されていると見なされる可能性があります。)

私は2つのリポジトリを提案します:

  1. リポジトリA:これはスクリプトをホストするだけです。ローカルで複製できます。
  2. レポB:これはデータを保持します。リモートホストにのみ複製する必要があります。

データマングリングスクリプトは、SSHまたは同様の方法でリモートホストにアクセスして、そこでデータを変更できると思います。データをリモートで変更したら、これらの変更を手動でコミットできます(ここでも、たとえばSSH経由で)。

より複雑なアプローチでは、ローカルリポジトリに変更をコミットすると、リポジトリBのリモート変更をコミットしてプッシュするリポジトリAのGitフックが必要になります。

また、Repo A内にRepo Bの現在のバージョンを指すGitサブモジュールを追加することもできます。これにより、RepoAが使用されたデータのバージョンを追跡できます。そのサブモジュールを実際にインスタンス化する必要はないことに注意してください(つまり、--recurse-submodulesを実行した場合に得られるもの)。これは、リビジョンへの単なるポインタです。

2
slhck

リモートリポジトリの使用isバージョン管理があります。リモートで作業する必要があるということだけです。それはおそらく「機密データをダウンロードできない」という精神に沿ったものが最善でしょう。

機密データの使用の正確な性質によっては、機密でないデータ/プログラムを使用してサーバーをセットアップし、偽の(テストケース?)機密データでサーバーを埋めることがおそらく最善です。安全な場所で、機密性の低いものを入手し、機密性の高いものを手元に置いておくことができるように設定します。そうすれば、機密データが漏洩(または破損)しないようにしながら、ダウンロードして自由にフロブし、すべてまたはgitの利点を享受できます。

あなたが私に尋ねるなら、私は誰かのマシンがp0wnされてデータが盗まれて- 開発プログラム/個人がそれにアクセスしているように聞こえます...賢明ではありません。最初に誰が/何がそれにアクセスできるかを確認しますまったく、次に残りについて心配します。

0
vonbrand