Git でプロジェクト バリアントを管理するためのベスト プラクティスにも同様の質問がありますか? しかし、文脈は異なり、答えもそうかもしれないと思います。
Xcodeで管理され、gitを使用してバージョン管理されたCocoa製品「First」があります。"First" はまだ進化中で、現在 3 番目のバージョンです。
次に、顧客が来て、Second と呼ばれる First のバリエーションを求めます。First から Second への変更は、多くのファイルに影響しますが、すべてのファイルには影響しません。変更はソース コードだけでなく、リソース (グラフィック要素、nib ファイル、プロパティ リストなど) にも影響します。
現在、2 つの製品は稼働しており、多数の共通ファイルを共有しています。ただし、バグ修正などの一部の変更は両方の製品に適用される場合があります。両方の製品に新機能が追加される可能性があります。
このようなシナリオを管理する最善の方法は次のとおりです。
- Xcodeで
- gitで
相互に排他的な 2 つのアイデアがあります。
アイデア 1: "First" を "Second" に git ブランチし、適用可能な変更を 1 つのプロジェクトから別のプロジェクトに適用します。これにより、2 つの完全に別個の Xcode ディレクトリとプロジェクトが作成されます。
アイデア 2:「Second」という名前のターゲットを Xcode プロジェクトに追加します。現在、同じ Xcode プロジェクトに 2 つのターゲットがあり、両方の製品の開発とビルドに使用されています。しかし、これにより、git で First と Second のリリースを管理することが難しくなります (リリースを同期する理由はありません)。
アイデア 2 は、並行開発プロセスを非常に簡単にします。コードは常に同期しています。相違は、コンパイル時の変数と単一のソース ファイル、または別のソース ファイルを介して処理できます。ただし、バージョン管理はより不明瞭になります。
アイデア 1 はおそらくよりクリーンですが、2 つのプロジェクト間で共通するものを管理するためのベスト プラクティスは何でしょうか? 2 つの git ブランチ間で「部分マージ」を行うことはできますか? 何に基づいて？それとも手動で処理する必要がありますか?
いくつかの共通部分をモジュールまたはライブラリにカプセル化して抽出することは可能かもしれませんが、常にそうとは限りません。たとえば、一般的なドキュメント アイコンでは、それは不可能だと思います。また、「最初に」をリファクタリングして、すべての一般的なアイテムをビルド可能な方法で抽出することは、私が一度に少しずつやりたい大きな仕事です。
完璧な解決策はないかもしれないことを理解しています。アイデアや提案を探しています。比較的最近の git 採用者として、これが RTFM の質問である可能性があることも認識しています。次に、FM to R を指定してください。
どうもありがとう。