私たちのプロジェクトでは、git repo でブランチを管理する方法を検討しています。私は有名な記事を読み、そのアイデアがとても気に入りました。このモデルは私たちにとって役立つはずです。
masterただし、この記事には、ブランチの存在に由来する隠れた仮定があります。リリースが遅いほど、そのバージョンは大きくなります。たとえば、2.0.1は常に の後にリリースされ1.5.10ます。したがって、マスターで各コミットをトラバースすると、バージョンは常に増加します。
これは、私たちのプロジェクトのケースには当てはまりません。顧客ごとにいくつかのバージョンを維持する必要があります。バージョン のサポート (および修正プログラムの提供) が必要な1.5お客様と、バージョンが のお客様がい2.0ます。明らか1.5.10に、この場合の version は、 version よりも (時間的に) 遅くなる可能性があり2.0.1ます。コミット後にコミット1.5.10しても意味がありません。master2.0.1
記事のモデルは私たちにはまったく適していませんか、それとも機能するように少し変更できますか?