Gitflowとセマンティックバージョニングの使用：マージ時にバージョン番号の競合を回避する方法
セマンティックバージョニングと組み合わせてgitflowを使用したいと思います。 gitflowでは、すべてのリリースまたはホットフィックスブランチでバージョン番号を上げます。現在のリリースプロセスがまだ進行中に新しい開発サイクル（新しいバージョン番号で）が開始された場合、これは必然的にバージョンの競合につながります。
たとえば、1.0.0がマスターで、開発時に新しい2.0.0リリースを開始するとします。これで、マスターからのホットフィックスが発生します（1.0.1）。修正プログラムを開発ブランチにマージすると、競合が発生します。
やや似たような質問 がSE @ Stackexchangeにありますが、大きな違いがあります。gradleとmavenビルドツールはバージョン番号に大きく依存しているため、コードに保存する必要があるだけで、リリースのビルド時にそれらを生成します。また、新しいリリースサイクルでは、開発時にバージョン番号を上げる必要があります。そうしないと、アーティファクトが上書きされます。
では、ブランチとバージョン番号を管理して、マージの競合が発生しないようにするにはどうすればよいですか？
このマージの競合を合理的に回避することはできません。しかし、これは非常に小さな競合であり、マージ中に簡単に解決できます。ただし、バージョン番号がoneソースファイルにのみ記述されていることを確認してください。
修正プログラムは、手動での解決で十分であるほどおそらくまれです。ただし、正しいバージョン番号が維持されているようなテストを追加するのが賢明な場合があります。コミットのバージョン番号がすべての親コミットから単調に増加していることを確認するスクリプト。バージョン1.0.1と2.0.0をマージすると、> = 2.0.0になる可能性があります。
Git-Flowが常に適用可能な分岐モデルであるとは限らないことに注意してください。それは、古いリリースをサポートする必要があるかもしれない明確でやや頻度の低いリリースがあるシナリオに向けられています。これは、既製のアプリケーションやライブラリに適しています。
Git-Flowは、すべてのデプロイメント/ユーザーを最新リリースに更新できる場合には適していません。社内ソフトウェア、SaaS、またはWeb /モバイルアプリ用。次に、リリースブランチのない別のブランチモデルがより適切な場合があります。これは、開発ブランチが常に解放可能な状態にあることを意味します。つまり、マージされたすべての機能がリリースの準備ができていることを意味しますORは機能トグルによって保護されています。修正プログラムは通常の次のリリースの機能であり、ホットフィックスのバックポート/マージは必要ありません。