NuGetとGitFlowの使用中のマージの競合を回避または最小限に抑える
ここに私たちの問題があります-独自のnugetパッケージを使用する複数のプロジェクトでいくつかのソリューションがあります。 GitFlowをフォローしていますが、SemVerはフォローしていません。より大きな機能やエピックを開発するたびに、開発ブランチ（前述のエピックの開発時に他の機能やバグ修正を行うことができる）でコードを最新に保ちたいので、定期的にマージしたいと考えています。問題は、すべてのマージで、nugetパッケージに変更があった場合、プロジェクトのすべてのpackages.configファイルでマージの競合が多数発生することです。そのようにすると、特にマージ後にnugetのバージョンを手動で更新してプロジェクトにインストールする必要があるため、マージに時間がかかりすぎます。したがって、何かをマージしたいときはいつでも、この手順を再現する必要があります。
- ブランチをマージ
- すべてのバージョンの競合を解決する
- 更新されたnugetパッケージをプッシュする
- 更新されたnugetパッケージをインストールする
私はいくつかの調査を行いましたが、このプロセスを簡略化するための最良の解決策はまだわかりません。 OK、GitVersionと組み合わせたフローティングバージョンでPackageReferenceまたはPaketを使用できます。これにより、開発ブランチのステップ3と4が自動化されますが、開発ブランチがリリースバージョン（XXX）を使用し、他のブランチが使用しているため、マージと競合の問題が残ります。プレリリースバージョン（-branchNameタグ付き）。したがって、すべての更新で競合が発生します。
だから私の質問は、その状況にどのように最もよく対処するかです。 nugetsを使用してこれを解決する方法はありますか、または他の方法でコードを共有できますか？私たちのライブラリは非常に大きく、私たちのソリューションに含めたくないので、共有プロジェクトは私たちの問題を解決しません。
OKこれが私の推測です。
Nugetによって配布され、アプリケーションによって使用される共有libがあります。
アプリケーションの機能リクエストを受け取ったら、そのリポジトリに新しい機能ブランチを作成しますが、共有ライブラリへの変更が必要になることがわかります
ライブラリリポジトリに機能ブランチを作成し、プレリリースナゲットを公開します
アプリケーション機能ブランチでプレリリースナゲットを使用し、機能のテストを続行します。
別のアプリケーション機能ブランチでも同じことが起こります。そのOtherFeatureを完了すると、ライブラリとdevブランチが更新されますが、OrigionalFeatureはまだプレリリースナゲットにあり、競合が発生します。
解決策は、アプリケーションとは無関係にライブラリに機能を追加してテストすることです。未完成のライブラリ機能を公開しないでください。終了する前に、公開する前にマスターにマージしてください。
ライブラリが新しい機能で更新されたら、アプリケーションを更新して最新バージョンを使用し、機能ブランチを作成できます。
これは明らかに、仕様をもう少し厳密に調べる必要があることを意味します。
または、ライブラリを同じバージョンとしてローカルにパックし、ディレクトリをファイルソースとして使用して、アプリのバージョンを更新する必要がないようにテストすることもできます。