前回に引き続き、無料のソースコード管理 (SCM: software configuration management) ソフト Git で用いられるブランチモデルのひとつである git flow の方式で、本番環境用の master ブランチにコミットする例を紹介します。
開発用の develop ブランチから分岐させた release/xxx ブランチで、master ブランチで公開したいファイル以外を除外して、master ブランチにそれをコミットしてバージョンを表すタグ付けを行います。

※Git-2.49.0 (64 bit) を使用します。
前回の記事
前回については以下の記事を参照してください。
master ブランチで、別のブランチの最新コミットをマージ
前回は、git flow ブランチモデルで、本番環境用(公開、納品など)のコミットを置く master ブランチに置くためのコミットを、開発用の develop ブランチから分岐させた release/github-0.1 ブランチで作成しました。
その release/github-0.1 ブランチの最新のコミットを、メッセージだけの1つのコミットしか持っていない master ブランチにマージ(合流)させます。
※以下の手順は git flow ブランチモデルの提唱を行ったページ「A successful Git branching model » nvie.com finishing-a-release-branch」を参考にしています。
master ブランチへの切り替え
git merge で release/github-0.1 ブランチの最新コミットをマージする対象である master ブランチへ git checkout コマンドで切り替えます。
git checkout <切り替えるブランチ名>
Switch branches or restore working tree files
ブランチの切り替えまたは作業ツリー ファイルの復元
Git – git-checkout Documentation
前後の git branch コマンドでは、 * が先頭についているブランチが現在のブランチであることを表しています。
git checkout master を実行すると、 master ブランチが現在のブランチに変わりました。
G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>git branch
develop
master
* release/github-0.1
G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>git checkout master
Switched to branch 'master'
G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>git branch
develop
* master
release/github-0.1
release/xxx ブランチの最新コミットを master ブランチにマージ
前回 release/github-0.1 ブランチで作成したコミットを、master ブランチにマージします。
#感覚的にマージは、 release/github-0.1 で行ったコミットの流れを、 master ブランチに合流させるものだと思います。
git flow ブランチモデルの提唱を行ったページ「A successful Git branching model » nvie.com finishing-a-release-branch」に従い以下のように –no-ff オプションをつけます。
git merge --no-ff <現在のブランチへマージするブランチ名>
–no-ff オプションについて
–no-ff の ff は fast-forward の略です。
この ff を有効にする場合、可能ならば、新しいコミットオブジェクトを作らずに、指定されたブランチの最新コミットのポインタを、現在のブランチにも設定するだけです。
例えば、指定したブランチに A -> B -> C というコミット履歴があった場合、現在のブランチは C というコミットを指すポインタを記録して共有するだけです。
release/github-0.1, master: A -> B -> C
この場合、現在のブランチに、指定されたブランチの最新コミットがマージされたという記録は残りません。
マージコミットが作成されないため、コミット履歴に分岐が起こらず、現在のブランチも、指定されたブランチの A -> B -> C を共有するため、直線的で変更履歴がわかりやすいコミット履歴を維持します。
Specifies how a merge is handled when the merged-in history is already a descendant of the current history.
--ff
is the default unless merging an annotated (and possibly signed) tag that is not stored in its natural place in therefs/tags/
hierarchy, in which case--no-ff
is assumed.With
--ff
, when possible resolve the merge as a fast-forward (only update the branch pointer to match the merged branch; do not create a merge commit). When not possible (when the merged-in history is not a descendant of the current history), create a merge commit.With
--ff-only
, resolve the merge as a fast-forward when possible. When not possible, refuse to merge and exit with a non-zero status.マージされた履歴がすでに現在の履歴の子孫である場合にマージを処理する方法を指定します。 refs/tags/ 階層内の本来の場所に格納されていない注釈付き (および場合によっては署名付き) タグをマージしない限り、–ff がデフォルトです。この場合、–no-ff が想定されます。
–ff を使用すると、可能な場合はマージを早送りとして解決します (マージされたブランチと一致するようにブランチ ポインターを更新するだけで、マージ コミットは作成しません)。不可能な場合 (マージされた履歴が現在の履歴の子孫ではない場合)、マージ コミットを作成します。
–ff-only を使用すると、可能な場合はマージを早送りとして解決します。不可能な場合はマージを拒否し、ゼロ以外のステータスで終了します。
Git – git-merge Documentation と Google 翻訳 (–no-ff だけ除去)
それに対して、git flow で用いる –no-ff は、マージコミット(例では Mc )を作成して、1個以上の他のブランチの変更(コミット)が、現在のブランチに取り込まれたという記録を残します。
先ほどの例でいえば、指定したブランチの A -> B -> C というコミット履歴の C を指すポインタを共有するのではなく、C を合流元の1つとして、現在のブランチに取り込んだ記録を持つ Mc というマージコミットが作成されます。
release/github-0.1: A -> B -> C
master : ┗ Mc
これにより、マージの記録が残りますが、master ブランチのコミット履歴には、他のブランチからの変更(コミット)を取り込んだ記録を持つ Mc というマージコミットが追加され、変更履歴が先ほどの直線的なものよりも複雑になります。
--no-ff
With
--no-ff
, create a merge commit in all cases, even when the merge could instead be resolved as a fast-forward.–no-ff を指定すると、マージが早送りとして解決できる場合でも、あらゆる場合にマージ コミットが作成されます。
Git – git-merge Documentation と Google 翻訳 (–no-ff だけを抜粋)
マージコマンド (–no-ff) の実行
git merge コマンドを現在のブランチ (master) で実行すると、以下のようにエラーメッセージが表示されました。
これは、各ブランチで共通の祖先となるコミット履歴がないために発生します。
G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>git merge --no-ff release/github-0.1
fatal: refusing to merge unrelated histories
master ブランチは、前々回に checkout –orphan を使って、メッセージだけの1個のコミットだけを持つようにして作られたため、指定した release/gihub-0.1 ブランチと共通のコミットがありません。
共通のコミットがない状況でマージをするには、–allow-unrelated-histories オプションを使います。
--allow-unrelated-histories
By default,
git merge
command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists or will be added.デフォルトでは、 git merge コマンドは、共通の祖先を共有しない履歴のマージを拒否します。このオプションを使用すると、独立して開始された 2 つのプロジェクトの履歴をマージするときに、この安全性を無効にすることができます。これは非常にまれなケースであるため、これをデフォルトで有効にする構成変数は存在しないか、追加される予定はありません。
Git – git-merge Documentation と Google 翻訳
以下のようにコマンドに –allow-unrelated-histories オプションを追加して実行します。
hint という行には「エディターがファイルを閉じるのを待っています…」(Google 翻訳)と書かれています。
G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>git merge --no-ff --allow-unrelated-histories release/github-0.1
hint: Waiting for your editor to close the file...
hint に書かれていたように、git merge を実行すると、 Visual Studio Code アプリが起動して、コミットのメッセージを求めるタブが開きました。
※エディタは、設定していたものが開かれます。

Merge branch 'release/github-0.1'
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
#最初の1行目は、提案されたメッセージ例だと思われます。
このマージが必要な理由を説明するコミット メッセージを入力してください。
特に、更新されたアップストリームをトピック ブランチにマージする場合はそうです。「#」で始まる行は無視され、空のメッセージは中止されます。
上記の # から始まるコメント文の Google 翻訳
コミット。
Visual Studio Code のタブ内に、コメントを追記して、念のため Ctrl + S で保存して(意味はなかったかも)から、そのタブを×ボタンで閉じました。

そのあと、コマンドプロンプトを見ると git merge が実行された結果が出力されていました。
G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>git merge --no-ff --allow-unrelated-histories release/github-0.1
Merge made by the 'ort' strategy.
.gitattributes | 17 +++++++++++++++++
.gitignore | 5 +++++
LICENSE | 21 +++++++++++++++++++++
README.md | 6 ++++++
4 files changed, 49 insertions(+)
create mode 100644 .gitattributes
create mode 100644 .gitignore
create mode 100644 LICENSE
create mode 100644 README.md
G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>
マージ (–no-ff) 結果の確認
git log コマンドで現在のブランチのコミット履歴を確認すると、合流元の release/github-0.1 ブランチのコミット履歴のあと、最新のコミット履歴として先ほど Visual Studio Code のタブ内で入力したメッセージ(#から始まる行は無視されています)を持つマージコミットが確認できました。

G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>git log
commit 258ea47de3eb64557a50bfd32e7fba3deb82f39e (HEAD -> master)
Merge: b240982 214b813
Author: さくらくらうど <メールアドレス>
Date: Sat Jun 21 17:19:22 2025 +0900
Merge branch 'release/github-0.1'
GitHub 公開用のリリースブランチを master に統合。
機能バージョン 0.1 に対応。記事用スナップショット。
commit 214b813f771e95a9410a7c89fa277417ab623105 (release/github-0.1)
Author: さくらくらうど <メールアドレス>
Date: Fri Jun 20 15:00:35 2025 +0900
prepare release: Include only some files
commit b2409829c183ce4bb2b39bc5104c2426c7fbde35
git ls-tree コマンドで、現在のブランチ (master) の管理しているファイルを確認すると、前回 release/github-0.1 ブランチで追加した4つのファイルがマージによって master ブランチにも引き継がれています。
G:\Dev\Godot4GD\SakuraCrowd\SakuraCrowdGodotLib>git ls-tree -r --name-only HEAD
.gitattributes
.gitignore
LICENSE
README.md
今回はここまで
次回に続きます。
参照サイト Thank You!
- Git
- TortoiseGit – Windows Shell Interface to Git
- A successful Git branching model » nvie.com
- Git – git-branch ドキュメント
- Git – git-rm Documentation
- Git – git-checkout Documentation
- Git – git-switch Documentation
- Git – git-log Documentation
- Git – git-restore Documentation
- Git – git-ls-tree Documentation
- Git – git-commit Documentation
- Git – git-cherry-pick Documentation
- Git – git-merge Documentation
- Git – git-tag Documentation
- Git – git-show-ref Documentation
- The Repository Browser – TortoiseGit – Documentation – TortoiseGit – Windows Shell Interface to Git
記事一覧 → Compota-Soft-Press
コメント