8

最初に: これは (願わくば) thisまたはthisの複製ではありません。

現在の状況:内部データベースの資格情報を含むファイルを Git リポジトリにコミットしました。一人で使っていたので良かったです。その後、私のグループはこのプロジェクトでクローン、プッシュ、プルを開始しました。現在、いくつかの Git リポジトリがあります (1 つの中央リポジトリと一部の開発者)。

問題:ソース コードと Git リポジトリへのパブリック アクセスを許可するか、少なくとも、コードに貢献している他のユーザーの詳細を Git に管理させたいと考えています。

質問:どのような戦略がよいでしょうか?

a) 中央リポジトリまたはすべてのリポジトリから認証情報を含むファイルを削除する、または

b) 新しい Git リポジトリを、外界への一種の「インターフェース」としてセットアップしますか?

(b) を選択した場合、変更をメイン リポジトリに簡単に伝えるにはどうすればよいでしょうか?

すでに広く配布されているため、現在のすべてのリポジトリでagit rebaseまたは aを実行したくありません。git filter-branch

4

4 に答える 4

10

申し訳ありませんがgit filter-branch、メイン リポジトリから資格情報を削除したい場合は、実行に行き詰まります。GitHub の人々によって書かれた機密データの削除を参照してください。

git の設計上、既存のクローンにそれぞれの履歴からファイルを強制的に削除させる方法はありません。

単一のブランチをサニタイズして、将来の開発の基礎にすることができます。

$ git checkout -b old-master master
$ git filter-branch ... master

サニタイズされたマスターを、クリーンなマスターのみを含む新しいリポジトリにプッシュする必要があります。

$ git push new-central master

既存のリポジトリは、必要に応じて新しいリモートとgit cherry-pick古いブランチからの変更を新しいクリーン マスターに追加できます。

新しいリポジトリについては、誰かが機密データをリポジトリにプッシュするのを防ぐために、何らかのバリアを配置して、同じ問題が再び発生しないようにします。この障壁は、新しい中央リポジトリを制御し、すべてのパッチをレビューして何が入るかを決定する人間である可能性があります。

于 2010-02-01T10:23:32.600 に答える
9

内部データベースのパスワードと、同じパスワードを持つ他のサービスのパスワードを変更するだけです。（履歴のどこかに存在する他のパスワードについても同じです）。

于 2010-02-02T02:09:30.290 に答える
2

リベースまたはフィルターブランチを使用せずに a) を実行する方法はありません。しかし、歴史を永遠に隠すのに苦労しなければならないよりも、今このようにする方がおそらく良いと思います. b)は、資格情報を削除するコミットの後に履歴を分割することで実行できると思います。その結果、2 つの異なるリポジトリに配置された 2 つの履歴が作成されます。1 つはクリーンアップ前、もう 1 つはクリーンアップ直後です。これらの 2 つのレポの歴史は、古い歴史に到達する必要がある人々のレポ内のグラフト ポイントを介して接続される可能性があります。

いずれにせよ、大量の sh*t を処理する必要があります。作業量が多い場合でも、a) とフィルター ブランチを使用することをお勧めします。

于 2010-02-01T10:23:37.673 に答える
1

それで、私たちは終わりました。最終的にどのようにそれを行ったかを共有したいと思います.

ある時点で誰もカスタム ブランチを持っていなかったという幸運な状況にありました。つまり、私たちが基本的に行ったことは、最後にすべてのものを中央リポジトリにプッシュすることでした。

次にfilter-branch、GitHubクルーが説明したように使用しました。その後、明確な中央リポジトリができました。

最後に (前述のように誰もローカル ブランチを持っていなかったためにのみ機能しました)、ローカル リポジトリを削除し、クリーンな中央リポジトリから新しいリポジトリを複製しました。

一言で言えば、このように、非常に迅速で痛みのない手順でした. エレガントではありませんが、うまくいきました。

于 2010-02-05T13:59:13.313 に答える