Q&A
masterから分岐してからの歴史すべてがmergeの対象となります。
前提
現在ある案件のGitの運用方法を変えようとしています。
masterのみで運用してるGitを、master,develop,featureに変更しています。
（もともと一人でGitを使っていたので、masterのみでしたが複数にで触ることになったので最低限？必要なブランチを作成した次第です。）
問題
掲題の通り、添付画像のように3,4でマージを行うと、developブランチのfeatureを切る前のコミットも一緒にmasterブランチへマージされます。
こちらは仕様なのでしょうか？
私の認識では、featureで変更された内容だけがmasterにマージされると考えていたのですが。。。
いくら調べても何も出てこなかったので、そもそもの「自分の認識が違っているのではないか？」と思い始めた次第です。
もし私の認識の方（featureのみがマージされる）正しければ、どういったことが問題なのか検討つく方がいらしたらご教授お願いできたらと思います。
回答2件
0
ベストアンサー
掲題の通り、添付画像のように3,4でマージを行うと、
developブランチのfeatureを切る前のコミットも一緒にmasterブランチへマージされます。
こちらは仕様なのでしょうか？
仕様です
私の認識では、featureで変更された内容だけがmasterにマージされると考えていたのですが。。。
feature ブランチを master ブランチへマージしたときは、
feature ブランチの最新リビジョンに至るまでの全てのリビジョンの内、
master ブランチに含まれていないリビジョンの更新内容がすべて反映されます
そのため、develop ブランチの master ブランチから分岐した後の各リビジョンの更新内容も
master ブランチに適用されることになります
relase ブランチという考え方
いわゆる、Git flow とか、A Successful Git Branch Model というブランチの分け方は
develop ブランチから feature ブランチを作成しているので、
develop ブランチの開発途中のコードが feature ブランチに混入している状態になります
そのため、feature ブランチを直接 master ブランチにマージせず
develop ブランチからQA、最終確認用の feature ブランチを作成し、
それまでの各 feature ブランチの変更を一度に master にマージすることになります
参考: 【Git】推奨されているブランチの分け方まとめ | ultra code
develop ブランチからマージするのが難しいとき
feature ブランチごとの制作の速度や規模に差があって
なかなか develop ブランチが安定せず
release ブランチの作成のタイミングが難しいこともあります
そのような場合は、master ブランチから feature ブランチを作成し、
CI を回すための develop ブランチにはマージだけを行い、
開発が完了したら feature ブランチを直接 release もしくは master にマージする方法があります
投稿2020/08/19 09:57
総合スコア3272
0
こちらは仕様なのでしょうか？
はい。
投稿2020/08/19 09:39
総合スコア147054
早速ご返信ありがとうございます。
なるほど、ずっと指定したブランチ内での編集のみがあたると勘違いしておりました。
ここで正せてよかったです。
では、もしfeatureの変更点をmasterにあてたいとなると、developでマージしたコミット（画像でいうと3番）をcherry-pickで引っ張ってくるのがオーソドックスな感じでしょうか？
チェリーピックなりプルリクエストなり、運用次第です。
なるほど、参考になりました。
ありがとうございます！
あなたの回答
tips
プレビュー
2020/08/19 10:28