オープンソース プロジェクトをカスタマイズする必要があります。変更は特定の組織向けであり、公開プロジェクトには役立ちません。コードの変更には、組織に不要な機能の無効化 (コードの 5% に影響)、組織の他の機能のカスタマイズ (コードの 20% に影響)、および新しいカスタム機能の追加 (約 10% の新しいコードの追加) が含まれます。
現在のバージョンから始めて、そこからカスタマイズすることができました。ただし、元のプロジェクトは引き続き進歩し、新しい機能が導入されているため、これらの改善を取り入れたいと考えています。
これを管理する最善の方法は何ですか? 現時点では、リリース バージョンが利用可能になったときにしか入手できませんが、元のプロジェクトの Subversion リポジトリへの読み取り専用アクセスがすぐにできるようになるはずです。Subversion リポジトリを使用するのは初めてですが、コードにも使用できるようにしています。
ベスト プラクティスは、最初に変更をプロジェクトにマージすることです。
それがオプションでない場合は、
ステップ 3 と 4 は、フォークを最新の状態に保つために関連しています。プロジェクトの活動と最新の状態を保つことの重要性によっては、大変な作業です。非常に重要な場合は、少なくとも週に 1 回は更新してマージします。
マージを簡単にするために、svn ツリーを git にインポートすることをお勧めします。これは、最も頻繁に行う作業です。
最善の方法は、フォークしないことです。それを改善する方法を見つけ出して、既存の機能を失うことなく、やりたいことを実行できるようにしてください。コード サイズが問題になる場合は、既存のプロジェクトの効率を改善するために、コードのフォークに費やす時間の一部を費やすことができます。
他の貢献者はあなたの「機能」を尊重しなければならないだけでなく、彼らはプロジェクトの第一級市民であるため、すべてのバグ修正を無料で入手でき、アップストリームで行われた変更があなたのものを壊すことはないので、あなたのものをアップストリームすることが最も安全な方法だと思います. それが実行可能なオプションでない場合は、サブバージョン ブリッジを使用したgitが適していると思います。分岐に役立つ多くの機能が既にあるためです。別のレポの一種のフォーク。
これはViskoの推奨事項の変形であり、ほとんどの時間を独自の変更に費やし、元のソースプロジェクトの新しいバージョンをたまにしか統合しないという反対の仮定があります。（以下のSubversion語彙を使用します。）
プロジェクトを作成し、元のソースをトランクとしてコミットします。鬼ごっこ。
ローカルで変更を加えたり、必要に応じてブランチを使用したり、リリースのためにトランクにマージしたりします。
統合したいoriginal-source-projectの新しいバージョンがある場合：
それは私が自分の使用のために頭の中で設計したプロセスです。それについてのフィードバックをお願いします。
プロジェクトリーダーと話をしましたか？あなたの変更は一般的に意味がありますか、それともあなたのニーズに非常に固有ですか？必要なものをメインプロジェクトに組み込むことができない場合は、確実にツリーを分岐して、マージを続けることができます。
部分的なマージ/パッチを受け入れるためのGIT（元のsvnとうまく相互作用できる）のようなものの機能も調べることができます。発散すればするほど、これが問題になります。もちろん、svnと優れたエディターを使用してそれを行うことができますが、より柔軟なツールを使用すると、作業が楽になる可能性があります。
元のプロジェクトのサブバージョン ダンプをインポートし、独自のリポジトリをブランチとしてフォークを開始します。元のプロジェクトが改善されたら、変更をインポートしてから、「svn merge」を呼び出してこれらの改善を組み込むことができます。あなたと元のプロジェクトが何らかの再構築 (ソース ファイルの名前変更、ディレクトリ間の移動など) を行わない限り、マージはほとんど機能するはずです。