ある Git ブランチを別の Git ブランチにマージする方法
マージには 2 つのコマンドが必要ですが、その指示につまずいてしまうため、Git が早送りしたり、マージ コミットを作成したりする可能性があります。正確なシーケンス、早送りの意味、いつどのオプションを使用するかは次のとおりです。
作者 Kodmora
GitTree の背後にあるソフトウェア ハウス
- マージ
- ブランチ
- マージ競合
このページでは
`feature` を `main` にマージするには、コミットを受け取るブランチに切り替えてから、もう一方のブランチをマージします: `git switch main` の後に `git merge feature` が続きます。 現在いるブランチが変更されるブランチです。 main に新しいコミットがない場合、Git はそれを早送りします。それ以外の場合は、マージ コミットが作成され、両方の側が競合する場合は停止します。
ブランチを段階的にマージするにはどうすればよいですか?
# get the latest
git fetch origin
# go to the branch that receives the work
git switch main
git pull --ff-only
# bring the other branch in
git merge feature/search
# publish it
git pushクリーンなツリーから始めます。最初にコミットまたはスタッシュします。途中で気が変わっても、`git merge --abort` が元に戻します。
マージはどちらに進みますか?
git merge X は常に「X を私がいるブランチに連れて行く」ことを意味します。したがって、feature を main にマージするのは main から行われ、feature を最新の main に更新するのは feature から行われます。
# keep a feature branch up to date
git switch feature/search
git fetch origin
git merge origin/main早送りマージとは何ですか?
他のブランチが離脱して以来、受信ブランチに独自のコミットがない場合、結合するものは何もありません。 Git はブランチ ポインタを他のブランチの最新のコミットに移動し、マージ コミットは追加しません。歴史は一直線です。これが発生すると、Git は Fast-forward を出力します。
# before
main: A---B
\
feature: C---D
# after a fast-forward merge
main: A---B---C---D両方のブランチに新しいコミットがある場合、早送りは不可能なので、Git は 2 つの親とのマージ コミットを作成します。 早送りレッスン と 分岐したブランチのマージ のレッスンでは、両方の実際の様子が示されています。
--ff-only、--no-ff、--squash は何をしますか?
| オプション | 結果 | こんなときに使います |
|---|---|---|
| (なし) | 可能であれば早送り、そうでない場合はマージコミット | ほとんどの毎日のマージ |
--ff-only | 早送り、またはエラーで停止 | リモートから main を更新しています |
--no-ff | 常にマージコミット | 各機能を履歴に表示したい |
--squash | すべての変更がステージングされ、コミットやマージは記録されません | きちんとしたコミットが 1 つ必要です |
git merge --ff-only origin/main
git merge --no-ff feature/search
git merge --squash feature/search
git commit -m "feat(search): quick open"マージが競合するとどうなりますか?
Git は停止し、競合したファイルにマークを付けます。それらを編集してそれぞれ git add し、git commit を実行してマージを完了します。 マージ競合を解決する方法 ではマーカーについて説明します。
片側を自動的に取得できますか?
# take their side wherever hunks conflict
git merge -X theirs feature/search
# take our side wherever hunks conflict
git merge -X ours feature/search
# during a merge, take one side of a whole file
git checkout --theirs path/to/file
git add path/to/fileマージまたはリベースする必要がありますか?
Merge は履歴を発生したとおりに保持し、コミットを書き換えないため、共有ブランチ上では常に安全です。 Rebase はコミットを別のブランチ上で直線的に再生しますが、書き換えるので、使用するブランチのみに留めてください。 マージとリベースのレッスン ではトレードオフを検討します。
合併後はどうすればいいですか？
# check that the branch is fully merged
git branch --merged
# delete it locally and on the remote
git branch -d feature/search
git push origin --delete feature/searchブランチを削除する方法 ではクリーンアップについて説明します。すでにプッシュされているマージを取り消すには、マージ コミットを元に戻す方法 を参照してください。
GitTree でブランチをマージする方法
受取ブランチを確認してください
コミットを受信するブランチ (
developなど) をダブルクリックします。マージするブランチを選択してください
新しい作業が含まれるブランチのラベルを右クリックし、Merge … into … を選択します。 1 つのラベルを別のラベルにドラッグすることもできます。
プレビューを読む
GitTree は最初にチェックを行い、競合せずにマージします、または競合により停止するファイルを通知します。
記録方法を選択する
[名前を付けて記録] で、可能な場合は早送り、そうでない場合はマージ コミット、常にマージ コミット、早送りのみ、または 段階的な変更に分割する (コミットなし) を選択し、マージ を押します。
すべてのオプションについては、ブランチのマージ を参照してください。
よくある質問
マージすると他のブランチは削除されますか?
いいえ、もう一方のブランチは元の場所に残ります。不要になったらご自身で削除してください。
GitHub でブランチをメインにマージするにはどうすればよいですか?
プルリクエストを開き、「マージ」を押します。代わりにローカルでマージする場合は、後で main を押します。ブランチ保護にはプル リクエスト ルートが必要な場合があります。
「すでに最新です」とはどういう意味ですか?
現在いるブランチには、他のブランチのすべてのコミットがすでに含まれているため、マージするものは何もありません。正しいブランチにいることを確認し、新しいリモート コミットが予想される場合は git fetch を実行します。
「無関係な歴史の結合を拒否する」とはどういう意味ですか?
多くの場合、リポジトリが 2 回初期化されたため、2 つのブランチは共通のコミットを共有しません。本当に参加したい場合は、--allow-unrelated-histories を追加してください。
スカッシュ マージは本物のマージですか?
スカッシュは変更をまとめてステージしますが、コミットもマージの親子関係も作りません。自分でコミットする必要があります。その後も元ブランチのマージは履歴に記録されないため、git branch -d が削除を拒否することがあります。
情報源
他の製品に関する申し立ては、2026年11月8日 の公式ページと照合して確認されました。価格と機能は変更されます。ベンダーのページが真実の情報源です。