git-flow-next

git-flow-next

git-flow-next（https://git-flow.sh/、リポジトリ gittower/git-flow-next） は、このスキルが対象とする Gitflow CLI です。 ほかの git-flow フォークは対象外です。

放棄されたフォークと混同しないでください

どちらのレガシーツールも git-flow バイナリを提供しているため、 混同しやすくなっています。

• nvie/gitflow — 2010 年頃のオリジナルのシェルスクリプトで、 10 年以上メンテナンスされていません。
• petervanderdoes/gitflow-avh — AVH フォークで、 現在は積極的に開発されていません。

command -v git-flow の解決先が mise の shim ディレクトリ外である場合、 または brew list に git-flow / git-flow-avh が表示される場合は、 git-flow-next をインストールする前に、以下の 古い git-flow / gitflow-avh からの移行手順に従ってください。 バイナリ名（git-flow）は同じなので、 $PATH 上で優先されるのは 1 つだけです。

厳守事項

1. git-flow-next のみを使用できます。 nvie/gitflow、gitflow-avh、シェルスクリプトのフォークは使用できません。

2. mise スキルに従い、mise の aqua バックエンド経由でインストールします。 mise.toml では aqua:gittower/git-flow-next としてバージョンを固定し、 mise.lock に記録します。 ここでは明示的な aqua: プレフィックスが必須です。 これは、裸の名前を推奨する mise スキルの方針に優先します。 裸の名前 git-flow は mise のレジストリで曖昧です （レガシー版の nvie/gitflow と gitflow-avh も同じ名前を使っています）。 そのため、git-flow-next を確実に選ぶ唯一の方法は、 aqua パッケージを直接指定することです。 brew install git-flow-next、 バイナリの手動ダウンロード、 go install は使用しないでください。

3. feature ブランチの上流へのマージ戦略には、1 コミットへのリベースを使用します。 finish の前に、ブランチを手書きのメッセージを付けた 1 つのコミットにまとめます （マージツールではまとめません）。 これにより、元の作者情報が保持され、WIP コミットごとのメッセージが develop 上で連結されるのを防ぎます。 各リポジトリで 1 回だけ、次のいずれか 1 か所で設定します。

   • ローカル finish ワークフロー — gitflow.branch.feature.upstreamstrategy = rebase を設定し、 git flow feature finish が feature ブランチを develop に対して 線形にリベースするようにします。 マージコミットは作成されません。 git flow feature finish を実行する 前に、ブランチを 1 つのコミットにまとめるのはコントリビューターの責任です （git rebase -i $(git merge-base HEAD develop) を実行し、 最初以外のすべてのコミットに fixup を指定した後、 クリーンなメッセージを設定します）。 upstreamstrategy = squash は使用しないでください。 元の作者情報なしで新しいコミットが作成され、 既定ではすべてのコミットメッセージが連結されます。 これは、この方針で避けようとしている動作です。
   • PR レビューワークフロー — このキーは設定せず、ホスティングプラットフォームの PR マージボタンを rebase and merge に設定します （「squash and merge」でも、通常の「create a merge commit」でもありません）。 コントリビューターはレビューを依頼する 前に、上記と同じ対話的リベースを使ってローカルでブランチを 1 つのコミットにまとめます。 こうすることで、コントリビューター自身が作成したクリーンな 1 つのコミットが develop に取り込まれます。 ホスティングプラットフォームの「squash and merge」は、 許容できる代替手段ではありません。 既定ではコミットごとのメッセージが本文に連結され、 プラットフォームの設定によっては、 できあがったコミットの作者がコントリビューターではなくマージ実行者になる場合があります。 マージ実行者は、すべての PR でこの両方を手動で修正する必要があります。

   各リポジトリではどちらか一方を選んでください。 両方を併用すると、処理が二重に適用されるか失敗します。 リリースとホットフィックスでは既定の merge 戦略を維持し、 マージコミットとバージョンタグが対になるようにします。

4. classic プリセットを使用します。 main と develop は長期運用ブランチです。 トピックのプレフィックスは feature/、release/、hotfix/、bugfix/ です。 ほかのプリセット（github、gitlab）はこのスキルの対象外です。 プロジェクトでいずれかが明示的に必要な場合は、 git-flow-next の公式ドキュメントを参照し、 このスキルの残りの内容は適用しないでください。

ドキュメントに照らした記憶の確認

git-flow-next はまだ新しく、リリースによってフラグ名、設定キー、プリセットの動作が変わります。 以下の内容（コマンドのフラグ、設定キー、プリセットの内容、バイナリ名、利用可能なバージョンなど）に見慣れない点や古い情報がある場合は、設定を書いたりコマンドを実行したりする前に https://git-flow.sh/docs で確認してください。 推測しないでください。

手順：mise でインストールする

このスキルではインストールするものを指定します。 mise スキルでは、その方法を定めています。必要な [settings] ブロックを含む mise.toml の作成、mise trust / mise install / mise ls、ロックファイル、コミットが対象です。 プロジェクトがまだ mise を使っていない場合は、まず mise スキルのセットアップ手順を実行してください。ここで手順を重複して記載しないでください。

git-flow-next 固有の手順：

1. 固定するバージョンを選びます （リリース： https://github.com/gittower/git-flow-next/releases）。

2. mise.toml の [tools] に、明示的に aqua: バックエンドを指定してエントリーを追加します。 pkgs/gittower/git-flow-next aqua パッケージには git-flow バイナリが含まれています。 また、Hard rule 2 では、ここで名前だけを指定するのが安全でない理由を説明しています。

   [tools]
   "aqua:gittower/git-flow-next" = "1.1.0"
   

3. mise スキルに従ってインストールした後、 git-flow-next 固有の確認を行います。

   git flow version
   

固定したバージョンが表示されるはずです。 別のバージョンが表示された場合は、別の git-flow バイナリが $PATH 上で mise 管理のバイナリを優先しているため、command -v git-flow で場所を特定して削除してください （よくある原因は、古い git-flow または git-flow-avh の Homebrew インストールです）。

手順：リポジトリを初期化する

リポジトリのルートから実行します。 classic プリセットは Gitflow のブランチとプレフィックスを設定します。 main ← develop ← feature/、 さらに release/、hotfix/、bugfix/ を設定します。 --defaults は対話形式のプロンプトを省略します。

git flow init --preset=classic --defaults

本番ブランチが main でない場合、またはブランチ名やプレフィックスを変更する必要がある場合は、--defaults を外し、代わりにドキュメントに記載されているオーバーライド（--main=master、--develop=…、--feature=feat/ など）を渡してください。

次に、ローカルで完了するワークフロー（Hard rule 3）では、feature の完了時に rebase を有効にします。

git config gitflow.branch.feature.upstreamstrategy rebase

PR レビューのワークフローでは、このコマンドを省略し、代わりにプラットフォームの PR マージボタンを「rebase and merge」に設定します。

確認します。

git config --get-regexp '^gitflow\.'

出力には、プリセットのブランチとプレフィックスの項目が表示されるはずです。 ローカルで完了するワークフローでは、gitflow.branch.feature.upstreamstrategy rebase も含まれている必要があります。PR レビューのワークフローでは、このキーが含まれていない必要があります。

手順：フィーチャーブランチのライフサイクル

以下では、ローカルで完了するワークフロー（ハードルール 3）について説明します。 コントリビューターはローカルでフィーチャーブランチを単一のコミットにまとめ、 その後、git flow feature finish でそのコミットを develop にリベースします。 PR レビューワークフローの場合は、以下の代替セクションに進んでください。

開始：

git flow feature start <name>

これにより、develop から feature/<name> が作成され、チェックアウトされます。 通常どおり作業します — 必要に応じて、コミットしてバックアップまたは共有のためにプッシュします。

公開（任意、共同作業の場合）：

git flow feature publish <name>

単一のコミットにまとめる（ハードルール 3）： 完了する前に、 現在の develop に対してフィーチャーブランチをインタラクティブにリベースし、 最初のコミット以外をすべて最初のコミットにまとめてから、 できあがったコミットメッセージを、明確で自己完結した要約に書き換えます。

git rebase -i $(git merge-base HEAD develop)
# In the editor: keep the first line as `pick`,
# change every following line to `fixup` (drops their messages) or
# `squash` (keeps and lets you edit them).
# Save and exit; if you used `squash` or `reword`,
# the editor reopens for the final commit message —
# write a clean, self-contained summary.

既存のコミットメッセージに残す価値がない場合の同等のショートカット：

git reset --soft $(git merge-base HEAD develop)
git commit -m "<clean summary of the feature>"

まとめた後、 git log develop..HEAD で表示されるコミットはちょうど 1 つです。

完了：

git flow feature finish <name>

upstreamstrategy=rebase が設定されている場合、次の処理が行われます。

1. develop に切り替えます。
2. （単一コミットになった）feature/<name> を develop に直線的にリベースします — マージコミットは作成されず、 元の作成者情報と手書きのメッセージが保持されます。
3. ローカルの feature/<name> ブランチを削除します。

その後、develop をプッシュします。 引数なしの短縮形は、現在のブランチで動作します。

git flow finish

まとめる手順を省略しても、 git flow feature finish はリベースを実行しますが、 フィーチャーブランチ上のすべての WIP コミットが個別のコミットとして develop に取り込まれます — これは、このスキルが徹底するポリシーに反します。 finish はフィーチャーブランチも削除するため、復旧するには develop 自体をインタラクティブにリベースし（git rebase -i origin/develop）、プッシュする前に新しいコミットを 1 つにまとめる必要があります — この方法が安全なのは、それらのコミットがまだローカルにある場合だけです。 まとめる手順を省略しないでください。

PR レビューの代替ワークフロー

PR レビューワークフロー（ハードルール 3）では、リベースマージは git flow feature finish ではなく、ホスティングプラットフォームの「リベースしてマージ」ボタンによって作成されます。 コントリビューターは PR を作成または更新する前に、引き続きローカルでブランチを単一のコミットにまとめます （上記と同じ git rebase -i ／ git reset --soft の手順です） — そうしないと、複数のコミットが develop に取り込まれ、ポリシーに反します。 PR のマージ後：

• リモートのフィーチャーブランチはすでに削除されています （通常の設定では、プラットフォームがマージ時に削除します）。
• git branch -d feature/<name> （または git flow feature delete <name>）でローカルのコピーを削除します。
• git flow feature finish は実行しないでください — 二重に適用されるか、失敗します。

手順：リリースブランチ

リリースではデフォルトのマージ戦略を維持し、 マージコミットとタグが対応した状態にします。

git flow release start 1.4.0
# bump version files, update changelog, commit
git flow release finish 1.4.0 --tag --message "release 1.4.0"

release finish は main にマージしてマージにタグを付け、 main を develop にマージし、 リリースブランチを削除します。

手順：ホットフィックスブランチ

git flow hotfix start 1.4.1
# fix, commit
git flow hotfix finish 1.4.1 --tag --message "hotfix 1.4.1"

hotfix finish は release finish と同様に、 main にマージし、 タグを付け、 main を develop にマージし、 ホットフィックスブランチを削除します。

手順：バグフィックスブランチ

バグフィックスブランチはフィーチャーブランチと同様に develop を対象としますが、 機能以外の不具合に限定されます。 本番環境の修正には hotfix を使用します。 ライフサイクルはフィーチャーブランチと同様です。

git flow bugfix start <name>
# fix, commit
git flow bugfix finish <name>

bugfix finish はデフォルトの merge アップストリーム戦略を使用します。 リポジトリで、フィーチャーブランチと同様にバグフィックスをまとめる場合 （ハードルール 3 に基づくローカル完了ワークフロー）は、 同様のキーを設定し、まとめてから完了する同じ手順（インタラクティブなリベース → 単一コミット → 完了）に従います。

git config gitflow.branch.bugfix.upstreamstrategy rebase

PR レビューワークフローでは、 バグフィックスブランチもフィーチャーブランチと同様に扱います — リベースマージはプラットフォームが実行し、 ローカルでは git flow bugfix finish を実行しません。

手順：旧 git-flow / gitflow-avh からの移行

command -v git-flow の結果が Homebrew または手動でインストールされた nvie/gitflow または petervanderdoes/gitflow-avh を指す場合、 または brew list / apt list --installed に git-flow または gitflow-avh が表示される場合に実行します。

1. 既存のセットアップがレガシーフォークであることを確認します： command -v git-flow を実行し、 次に git-flow version を実行します — レガシーの AVH フォークは AVH Edition と表示され、 nvie のものは Go/Tower の表記がなく、0.4.x のようなバージョンを表示します。

2. レガシーの Gitflow 設定を読み取ります — ブランチ名とプレフィックス名の抽出だけに使用し、 そのまま再適用しないでください。 レガシーフォークと git-flow-next ではキーのスキーマが異なります （レガシー：gitflow.branch.master、gitflow.prefix.feature； git-flow-next：gitflow.branch.<type>.parent、 gitflow.branch.<type>.prefix）。 そのため、取得したキーをそのまま再利用することはできません — git flow init のフラグ値の参照元として使用します：

   git config --get-regexp '^gitflow\.'
   

   gitflow.branch.master、 gitflow.branch.develop、 gitflow.prefix.feature、 gitflow.prefix.release、 gitflow.prefix.hotfix、 gitflow.prefix.bugfix の値を控えます。

3. 古いバイナリを削除します：

   • Homebrew：brew uninstall git-flow または brew uninstall git-flow-avh。
   • 手動インストール：$PATH 内の場所からバイナリを削除します。

4. 上記の手順で git-flow-next をインストールします。

5. git flow init を再実行し、 手順 2 で控えた名前を上書き値として渡します （値がクラシックプリセットのデフォルトと一致するフラグは省略します）：

   git flow init --preset=classic \
     --main=<captured master/main> \
     --develop=<captured develop> \
     --feature=<captured feature prefix> \
     --release=<captured release prefix> \
     --hotfix=<captured hotfix prefix> \
     --bugfix=<captured bugfix prefix>
   

   控えた値がすべてクラシックのデフォルトと一致する場合は、 git flow init --preset=classic --defaults だけで十分です。

6. ワークフローに従ってリベース設定を再適用します（厳守ルール 3）：

   • local-finish： git config gitflow.branch.feature.upstreamstrategy rebase を実行し、 すべてのフィーチャーで圧縮してから終了する手順 （インタラクティブリベース → 単一コミット → git flow feature finish） に従います；
   • PR-review： 設定は省略し、 プラットフォームの PR マージボタンを「リベースしてマージ」に設定し、 PR を作成する前にフィーチャーブランチをローカルで単一コミットに圧縮します。

7. git flow version が mise.toml の git-flow-next バージョンを報告し、 command -v git-flow が ~/.local/share/mise/ （または mise がシムを配置する場所）を指すことを確認します。

報告

変更後、 追加または更新した mise.toml の項目 （ツール、バックエンド、バージョン）、 設定した gitflow.* キー、 削除したレガシーバイナリ、 およびユーザーが次に実行するコマンド （git flow version、 git flow feature start <name>、 または現在のタスクに適したコマンド）を伝えます。