SourcetreeとBitbucketを使ったマージの方法

Question

git初心者です。SourcetreeとBitbucketを使って運用(試用)しています。

自身の作業ブランチ(仮にdev)をmasterにマージさせたい場合には、以下のような手順で行えばよいと考えています。

A

1. アド、コミット後、リモート内のdevにプッシュする
2. プルリクエストを作成する
3. 承認後、masterにマージする(このときリモートのdevをクローズする)
4. リモートのmasterをフェッチする
5. origin/masterをmasterにマージする
6. ローカルのdevを削除する

---

その一方で、ネット上では下記の方法が紹介されていました。

B (Aの3までは同じ)

1. 上記3.のマージ後、devをチェックアウトしたままmasterをプル(origin/masterをマージでも同じ?)
2. マージした変更をコミットし、再度リモート内のdevにプッシュ
3. masterをチェックアウトしてmasterをプル(origin/masterをマージでも同じ?)
4. 最後にdevを削除する

(参照：https://nodoame.net/archives/10312)

---

上記の方法で行う必要性(理由)はあるのでしょうか。Aの3でリモートのdevを削除したのにもかかわらず、Bの1,2でdevにmasterをプルし、再びそれをプッシュする理屈がよくわかりません。しかし、Bの方法でトライしても何ら問題ないため、なおさら混乱しています。
この理屈と適切なマージの方法についてご説明いただけると幸いです。

よろしくお願いいたします。

Answer 1

プルリクエストをマージしたあとのmasterブランチだけに着目すると、

A
リモートのmasterをフェッチする (A-4)
origin/masterをmasterにマージする (A-5)

B
masterをチェックアウトしてmasterをプル (B-3)

となっており、同じことをやっているので、同じ結果になることは理解できると思います。

devについては最終的に削除するなら、途中の操作は意味がありません。
なのでBの操作は無駄が多いように感じます。

gitに関しては、適切な方法というのは、一緒に作業するチームや、運用ルールによってまちまちなので一般論でいうのは難しいです。
rntkさんのやりたいことがAでできているなら、Aのやり方でいいのではないでしょうか。

Comments

[rntk]

ご回答ありがとうございました。
一般論でいうのは難しいとのことですので、チーム内で検討したいと思います。
また、Bの操作は無駄が多いということ、参考になりました。