2

レガシー Java プロジェクト A があるとします。そのプロジェクトには、何らかの理由で機密情報 (パスワード、暗号化キー、電子メールなど) や環境固有のもの (ハードコードされたパス、サーバー名、電子メールなど) が含まれています。関連する複雑さのために、ソース コードに情報を含めないようにプロジェクトを変更することはできないようです。

ある時点で、新しいアウトソーシング チームが開発に参加します。上記の状況では、アウトソーシング チームはプロジェクト ソースに逐語的にアクセスできません。彼らは別の開発環境を持っているので、問題が解決されたプロジェクトの別のコピーを VCS に作成することができます (つまり、必要なものはすべて、環境で動作するために必要に応じてクリーンアップ/更新されます)。そのバージョンを A2 としましょう。

ワークフローには通常、A と A2 に関連する 2 つのものが含まれます。

  • コードは両側で変更される可能性があります (つまり、A と A2 の両方が変更される可能性があります。A は元のチームによって変更され、A2 はアウトソーシング チームによって変更されます)。これには、ソース コード変更の競合が含まれます。
  • 2 つのプロジェクトの同期を保つ必要があります。それらを常に同期させる必要はありませんが、それを行うための比較的簡単な方法を用意することが重要です。解決すべき競合がある場合、これは手動プロセスである必要があると想定されます

このワークフローは、2 つのプロジェクトを手動で保持し、それらをマージすることで実現できます。

関連する質問:

  • git を使用して 2 つのバージョンを管理するにはどうすればよいでしょうか。つまり、手動のマージと比較してどのようなオプションがあるのでしょうか?
  • これが最適な設定ですか、それともより良いオプションがありますか?
  • 新しいプロジェクトの場合、機密/環境固有のものをソース管理から除外するための好ましい方法は何ですか? とにかくそれは良いことですか？
4

2 に答える 2

1

このアプローチはあなたを苦しめます。あなたがする必要があるのは、使用git filter-branchしてサーバー名を削除し、パスワードを削除して、機能しない一般的な形式に置き換えることです。つまり、実行されるべきではありません - どこでも!

次に、smudge/clean スクリプトをセットアップして、その情報を含むファイルを変更し、そのローカル システムでのみソリューションを実行するために必要な値を設定します。開発環境と比較して、本番環境には異なるパラメーターがあります。重要なのは、この情報を抽象化することです。

これで、アウトソーシングされたチームと同じリポジトリを共有しても問題はありません。リポジトリ間でコミットをスクラブするよりも、1 つのリポジトリでブランチを管理する方がはるかに簡単です。

于 2012-10-30T17:27:41.240 に答える