Git で次のような状況があるとします。
作成されたリポジトリ:
mkdir GitTest2 cd GitTest2 git init
マスターでいくつかの変更が行われ、コミットされます。
echo "On Master" > file git commit -a -m "Initial commit"
Feature1 がマスターから分岐し、いくつかの作業が完了しました:
git branch feature1 git checkout feature1 echo "Feature1" > featureFile git commit -a -m "Commit for feature1"
一方、マスター コードにバグが発見され、ホットフィックス ブランチが確立されます。
git checkout master git branch hotfix1 git checkout hotfix1
バグはホットフィックス ブランチで修正され、マスターにマージされます (おそらくプル リクエスト/コード レビューの後)。
echo "Bugfix" > bugfixFile git commit -a -m "Bugfix Commit" git checkout master git merge --no-ff hotfix1
機能1の開発は継続中です:
git checkout feature1
たとえば、バグが機能ブランチでも発生するため、機能ブランチに修正プログラムが必要だとします。コミットを機能ブランチに複製せずに、これを実現するにはどうすればよいでしょうか?
機能実装とは関係のない 2 つの新しいコミットが機能ブランチに作成されるのを防ぎたいです。プル リクエストを使用する場合、これは特に重要なようです。これらのコミットはすべてプル リクエストに含まれ、レビューする必要がありますが、これはすでに実行されています (ホットフィックスはすでにマスターにあるため)。
「致命git merge master --ff-only
的: 早送りできません。中止します。」というメッセージは表示されませんが、これが役に立つかどうかはわかりません。
ベストアンサー1
マスター ブランチを機能ブランチにマージするにはどうすればよいでしょうか? 簡単です:
git checkout feature1
git merge master
ここで Fast Forward マージを強制しても意味がありません。実行できないからです。機能ブランチとマスター ブランチの両方にコミットしました。これで Fast Forward は不可能になります。
見てGitFlowこれは、従うことができる Git のブランチ モデルであり、無意識のうちにすでに実行されています。また、これは Git の拡張機能であり、手動で行う必要がある作業を自動的に実行する新しいワークフロー ステップ用のコマンドをいくつか追加します。
では、ワークフローで正しく行ったことは何でしょうか? 作業するブランチが 2 つあり、feature1 ブランチは基本的に GitFlow モデルの「develop」ブランチです。
マスターからホットフィックス ブランチを作成し、それをマージし直しました。そして、行き詰まってしまいました。
GitFlow モデルでは、修正プログラムを開発ブランチ (この場合は「feature1」) にもマージするように求められます。
したがって、本当の答えは次のようになります。
git checkout feature1
git merge --no-ff hotfix1
これにより、ホットフィックス内で行われたすべての変更が機能ブランチに追加されますが、それらの変更のみが追加されます。ブランチ内の他の開発変更と競合する可能性がありますが、機能ブランチを最終的にマスターにマージし直しても、マスター ブランチとは競合しません。
リベースには十分注意してください。変更がリポジトリにローカルにとどまっている場合のみ、つまり、他のリポジトリにブランチをプッシュしていない場合のみ、リベースしてください。リベースは、ローカルコミットを便利な順序に整理してから世界にプッシュするための優れたツールですが、その後のリベースは、あなたのような Git 初心者にとっては混乱を招きます。