web-dev-qa-db-ja.com

git flowを使用してリリースする場合、pom.xml内のバージョンをどのように更新する必要がありますか？

Mavenプロジェクトでは、プロジェクトのバージョンはpom.xmlファイルの<version>属性に含まれています。 git flowモデルで新しいリリースを作成するとき、バージョン番号を変更する必要があります。 この記事 これがどのように行われるかを説明します（Mavenなし）：

  1. リリースブランチを作成する
  2. バージョン番号を変更してコミットする
  3. 開発とマスターの両方のためにリリースブランチをマージします

さらに、それは言います：

リリースブランチの開始時に、次のリリースに以前のバージョン番号ではなくバージョン番号が割り当てられます。それまで、開発ブランチは「次のリリース」の変更を反映していましたが、リリースブランチが開始されるまで、その「次のリリース」が最終的に0.3になるのか1.0になるのかは不明です。その決定は、リリースブランチの開始時に行われ、バージョン番号バンピングに関するプロジェクトのルールによって実行されます。

ここでは、Mavenに関連する2つの問題があります。

  1. Mavenで開発中のバージョンは[次のバージョン] -SNAPSHOTになります。そのため、リリースブランチを作成する時点で、次のバージョンの決定を延期することはできません。もちろん、後で考えを変えることができるなら、すでにここで/ some value /を入力する必要があります。
  2. リリースを作成する前に、pom.xmlのバージョンは1.1-SNAPSHOTとしましょう。これをリリースブランチで単に1.1に変更し、それをマスターにマージしました。いいよしかし、開発のためにそのブランチをマージする必要もあります。そのためには、バージョンをたとえば1.2-SNAPSHOT。そしておそらく、コミットはリリースの一部であってはならないので、リリースブランチでそれをすべきではなかったでしょう。実際には、開発に関するすべての将来のコミットは次のバージョンに向けられるため、開発を分岐した直後にこの変更を行う必要がありました。

問題をグーグルで調べたとき、プロセスを自動化できるmaven-pluginsに関する記事を見つけましたが、これは興味深いかもしれませんが、この質問は実際にはgitグラフがどのように見えるべきか、バージョンバンプコミットはどこにあるべきかではなく、 maven-pluginを使用してこれを自動化します。

gitmavenversioninggit-flow
23
yankee

通常のリリースでは、リリースブランチをマージした後、スナップショットバージョンバンプを実行します。

  1. developからリリースブランチを作成し、バージョンからスナップショットを削除します
  2. masterにマージします
  3. developにマージします
  4. developのバージョンを次のスナップショットバージョンに変更します
  5. masterとdevelopの両方をプッシュします

すべての変更を同時にプッシュすると、チームにはスナップショットバージョンの増加のみが表示されます。

ホットフィックスの場合、masterブランチから作成するため、これは不可能です。このシナリオには回避策があります。生のgitコマンドを使用した例を次に示します。

例：masterに1.0.0があり、1.0.1修正プログラムバージョンを作成する場合。開発はすでに1.1.0-SNAPSHOTにあります。

  1. git checkout master
  2. git checkout -b hotfix/1.0.1
  3. 修正プログラムを作成してください！
  4. mvn versions:set -DnewVersion=1.0.1
  5. git commit -a -m "hotfix release 1.0.1"
  6. git checkout master
  7. git merge hotfix/1.0.1（簡単、masterから分岐を作成したため）
  8. git checkout develop
  9. mvn versions:set -DnewVersion=1.0.0
  10. git commit -a -m "workaround to avoid merge conflicts"
  11. git merge hotfix/1.0.1（以前のコミットにより機能します）
  12. mvn versions:set -DnewVersion=1.1.0-SNAPSHOT
  13. git commit -a -m "set version back to 1.1.0-snapshot"

あまりいいとは言えませんが、うまくいきます。このソリューションはjgitflow（git flowでサポートするMavenプラグイン）でも使用されます

4
chris

Gitは、独自のバージョンルールを持つLinuxカーネル用に開発されたことに留意してください。

Mavenの場合、次のリリースのスナップショットバージョンを取得するリリースブランチを作成する必要があります。この変更は、単一のコミット（つまり、pom.xmlのバージョン番号の変更）である必要があります。それをマージするとき、masterをチェックアウトし、git merge --strategy=ours <release-branch>を使用します

--strategy=oursの意味：「masterのすべてがリリースブランチと正しくマージされました」と言ってマージを行います。マスターに変更は加えられていません。その後、Gitは両方のブランチのバージョン番号が異なっていても、ブランチをマージされた（つまり、変更がない）ものとして扱います。

Mavenでmasterをビルドする際にあらゆる種類の問題を回避するには、99.DEV-SNAPSHOTのように変化しない、奇数または非常に高いバージョン番号を使用します。

リリースを作成したら、リリースブランチのバージョンから-SNAPSHOTを削除してコミットします。その後、マスターをチェックアウトし、--strategy=oursともう一度マージします。

注：これを行う場合、リリースブランチで他の変更を行わずに、バージョンを変更する必要があります。その他の修正プログラムはすべて失われます！チェリーだけを選ぶことができます。

3
Aaron Digulla

jgitflow-maven-plugin ：ゴール jgitflow：release-start および jgitflow：release-finish を使用できます。

1
numéro6

Mavenでは、notバージョン番号を手動で変更する必要があります。

Mavenにコミットしてバージョン変更を直接プッシュさせるために、「scm」情報をpomに追加する必要があります。

次に、「リリースプラグイン」を使用します。それはあなたのために仕事をします。現在のバージョンが「1.1-SNAPSHOT」であると仮定すると、「release：perform」mavenタスクは次のようになります。

  • バージョンを1.1に変更し、コミットし、このバージョンにタグを付けてプッシュします。
  • バージョンを1.2-SNAPSHOT（または1.1.1-SNAPSHOT、2.0-SNAPSHOT…次のバージョンを選択できます）に再度変更し、コミットしてプッシュします。

以下は、Mavenリリースプラグインが使用されているプロジェクトのgit履歴の抜粋です。

* 2345678 - Normal developpement commit (on branch 1.2-SNAPHOT).
* 5678901 - [maven-release-plugin] prepare for next development iteration
* 8901234 - (tag: 1.1) [maven-release-plugin] prepare release 1.1
* 1234567 - Normal developpement commit (on branch 1.1-SNAPHOT).

注1：リリースの時点で、次のバージョン（この例では1.2）をプロビジョニングする必要があります。気が変わったら、後で変更できます。 Maven "version：set-version"プラグインを使用すると、すべてのプロジェクト階層のバージョンを再割り当てできます。次のリリースまでにこのバージョンの変更をコミットする必要があります。

注2：リリースの時点で、リリースバージョンを変更することもできます。現在のバージョンが1.1-SNAPSHOTであっても、リリースが2.0バージョンであり、次の開発バージョンが2.1-SNAPSHOTであると判断できます。

0
Benoit Courtine