web-dev-qa-db-ja.com

バージョンはdevブランチまたはmasterブランチにバンプする必要がありますか?

マスターブランチ(デフォルトブランチ)でAPI 1.0.0をリリースしました。それ以来、私は別々にブランチにブランチしていますapi2/fooおよびapi2/bar、どちらにも下位互換性のない変更が含まれています。

APIバージョンはソースコードで宣言されます。両方のapi2/*ブランチ、またはマスターブランチでバージョンを2.0.0にバンプする必要がありますか?

マスターブランチのバージョンをバンプすると、api2/*ブランチのソースコードのバージョンが更新されません。ブランチの開発ビルドをリリースする場合、プロジェクトがAPI 1であると宣言したときにAPI 2のものが使用される可能性があります。その結果、マスターブランチにコミットをマージして、バージョンをバンプする必要がありますが、私は結合しますmasterブランチの他の変更もすべて一緒にしたいので、まだ実現したくありません。

一方、devブランチでバージョンをバンプすると、2つのコミットでバージョンがバンプされるため、両方がマスターブランチにマージされると、競合が発生する可能性があります。

これらの2つのオプション間の良い解決策は何でしょうか?

3
SOFe

CIサーバーでリリースをビルドするときに、コードにバージョンを付けます。

通常、これは開発のためのチェックインです。開発ブランチがない場合はマスターしてください。

機能ブランチをバージョン管理すると、「最新」バージョンが明確に定義されていないため、問題が発生します。

開発ブランチがなく、両方の変更に互換性がないため、次のことを行う必要があります。

  • fooをマスターにマージし、v2をビルドする
  • マスターをバーにマージし、非互換性を修正
  • バーをマスターにマージし、v3をビルドする
4
Ewan

根本的な問題は、適切なコミットサイズとは何ですか?

私のアドバイスは、コミットには単一の完全な変更が含まれている必要があります。

「単一」とは、変更された行の最小量を意味します。
「完了」とは、プロジェクトがコンパイルされ、すべての自動テストが正常に実行されることを意味します。

その意味で、「バージョンバンプ」とは、そのような単一の完全な変更です。

その「バージョンバンプ」が別のコミットにある場合は、マージする前にgit rebase -iまでにそのコミットを削除(スキップ)することができます。

4
Timothy Truckle

私の意見では、両方のブランチを別々に2.0.0に更新することは賢明ではありません。これは、両方のブランチがバージョン2.0.0を表すことを意味するためです。しかし、これらは互いに互換性がないため、明らかに矛盾しています。同じバージョン番号の互換性のない2つのビルドを作成すると、そもそもバージョン管理の目的全体が無効になります。

両方をリリースブランチにマージするか、fooをbarにマージ(またはその逆)してから、バージョンを2.0.0にバンプする必要があります。その後、それをマスターにマージして戻すことができます。

2
Pete

これをどのように選択するかは、パイプラインの外観に依存します。

以前に安定したリリースバージョンを使用していた場合、互換性のないバージョンの使用を誤って開始する方法はないはずです。これは、配布されるアーティファクトをビルドする最初の機会の前にバージョン番号を変更する必要があることを意味します(機能に取り組んでいる開発者によるローカルビルドは問題ありません)。

他の誰かが使用する可能性のあるアーティファクトを構築する唯一の方法は、新しいバージョンを指定する必要があるビルドサーバーでジョブを実行することであり、ビルドサーバーが更新されたバージョンでコミットをプッシュするようにするパイプラインを使用できます。数。

たとえば、「進行中」のブランチへの自動アップグレードを防止するバージョン管理スキームを実装できます。使用する依存関係マネージャーが修飾子付きのバージョンに自動的にアップグレードしないことを確認し、すべてのチェックアウトで「-branch-name "をバージョン番号に追加します(自動パイプラインがある場合は、ビルドごとに代わりにその修飾子を追加できます)。

すでにブランチがあり、他に解決策がないように見えるので、両方のブランチを「2.0.0-SNAPSHOT」としてマークし、それらをマージしてから、「2.0.0」にバンプします。同じ変更を2回行ってもマージの競合は発生しません。マージの競合があれば、解決は簡単です。 「SNAPSHOT」修飾子を使用すると、バージョンが「フル」2.0.0(私がよく知っているほとんどの依存関係マネージャー)としてカウントされなくなり、2.0の間は進行中の作業であることを人間に明確に示します。 0を指定すると、下位互換性がないことを示すことができます。

0
Jacob Raihle