プロジェクトを別のプラットフォームに移植しようとしていますが、この新しいプラットフォームと最初に使用したプラットフォームとの間にいくつかの違いがあることがわかりました。それを支援するはずの autotools パッケージと構成スクリプトを見てきましたが、新しいプラットフォームごとに個別のブランチを用意することがどれほど実現可能か疑問に思っていました。
私が目にする唯一の問題は、ターゲット プラットフォームで開発を行い、プラットフォームに依存する変更を取得せずに他のブランチに変更をマージする方法です。それを行う方法があれば、もっときれいになると思います。
このアプローチを推奨/阻止できる人はいますか?
私は間違いなくそのアプローチを思いとどまらせます。
マージできないブランチに同じコードを保持すると、問題が発生するだけです。どのブランチにどの変更が適用されたかを追跡するのは信じられないほど混乱し、プラットフォーム ブランチの 1 つに変更を適用するのを忘れると悪夢になります。
言語については言及しませんでしたが、言語で利用可能な機能を使用して、プラットフォーム間のコードの違いを分離しますが、1 つのブランチを使用します。たとえば、C++ では、最初にファイル ベースの分離を使用する必要があります。たとえば、Mac、Linux、および Windows プラットフォーム用のサウンド コードがある場合、sound_mac.cpp、sound_windows.cpp、および sound_linux.cpp ファイルを作成します。それぞれに同じクラスとメソッドが含まれていますが、プラットフォーム固有の実装は大きく異なります。明らかに、特定のプラットフォームの IDE に適切なファイルを追加するだけです。したがって、Xcode プロジェクトは sound_mac.cpp ファイルを取得し、Visual Studio プロジェクトは sound_windows.cpp ファイルを使用します。これらのクラスとメソッドを参照するファイルは、#ifdef を使用して、含めるヘッダーを決定します。
インストーラー スクリプトなどにも同様のアプローチを使用します。Mac と Windows ではインストーラーが異なる場合がありますが、両方のファイルがブランチにあります。Mac 上のビルド スクリプトは、単に Mac 固有のインストーラー ファイルを利用し、Windows 固有のファイルを無視します。
物事を 1 つのブランチに保持し、現在のプラットフォームに当てはまらないものを無視するだけで、トピック ブランチとマスターの間を行ったり来たりすることができ、生活がより健全になります。
ターゲットプラットフォームの互換性を検討するための分岐は実行可能です。ターゲットプラットフォームとは関係のない変更を、特に別のブランチに分けてください。