【Behindの解決】gitでdevブランチから変更点をもらうときはrebaseかmergeどちらがいいのか？

結論

特にmergeで困らない。

　　　　　終
制作・著作
　　━━━━━
　　ⓃⒽⓀ

ということで、混ぜる時はマージを使いましょう。

はじめに

ここで書いている記事は、かなり自分が調べたり、周りの人に聞いた内容を極端に解釈して、結論づけた記事です。
間違いや、流石にぶっ飛びすぎなどがあれば、フィードバックをもらえると助かります。

なぜ変更点を反映させるのか（Behindを解決するのか）

aheadは元となるブランチから見て、７コミット進んでいる。
behindは元となるブランチから見て、２２コミット後ろにいることがわかる。

ブランチは前に進む（コードが進む）ことは問題はないのだが、コードが後ろにいることは問題である。

詳しい使い分け

引用元
https://blog.codecamp.jp/git_rebase

rebaseとmergeの違い

ブランチがこのようにある時に、rebaseとmergeを見比べてみる。

画像引用元
https://www.atlassian.com/ja/git/tutorials/merging-vs-rebasing

rebase

rebaseをすると、根本の位置をmainの最新の場所にずらして適応をする。

画像引用元
https://www.atlassian.com/ja/git/tutorials/merging-vs-rebasing

メリット

gitTreeで交差や長いラインを作ることが減るため、みやすくなりコンフリクトが起きづらくなる。
gitTreeを一本化することができる。

デメリット

歴史改変を行なっているため、破壊的な変更である点。
そのため、一度レポジトリにPushをしてしまうと強制プッシュを行わなければ変更をすることができない。
しくじると、かなりめんどくさいことになる。

どういったときに使うといいか。

• Gitをそれなりに使えて、尚且つ、GitTreeを綺麗にしたいときに使う。
• まだプルリクを送ってなくて、チームのメンバーがそのブランチで作業をしていないことが重要。
  • コンフリクトの原因になったり、他の人で同じブランチがリモートとローカルで二つあるように見えて混乱を起こす場合がある。

merge

mergeをするとmainの変更点をfeatureに反映させて保存をさせる。

画像引用元
https://www.atlassian.com/ja/git/tutorials/merging-vs-rebasing

メリット

破壊的な変更を行わないため、しくじることが少ない
間違えてしまっても、mergeしたコミットを消すだけで変更を取り消すことができる。
一度レポジトリにPushをしても使うことができる

デメリット

GitTreeが交差したり、長くなったりして少しみにくくなる（複雑になる）。
GitTreeが見にくいとコンフリクトが起きやすい？（うわさ程度

どういったときに使うといいか。

• Gitに慣れていなくて、まだおぼつかない時はこちらを使う。
  • コミットを消すだけでマージを消せるため
• プルリク後などで、他の人がすでに自分の作業ブランチを用いてPullや作業を行っている場合。

具体的なmergeで変更点を取り込む方法

// developの変更点をもらう
git checkout develop
git pull origin develop

// developの変更点を自分のブランチに反映する。
git checkout feature
git merge develop

具体的なRebaseを用いた変更点を取り込む方法

// developの変更点をもらう
git checkout develop
git pull origin develop

git checkout feature
git rebase develop
//　コンフリクトがあれば、ここで解決を行う。　何回かコンフリクトがあれば、何回かコンフリクトの解決とadd と　rebase --continueを繰り返す。
git add -A
git rebase --continue

まとめ

今回behindの解決として、二つのやり方をご紹介しました！！
GitTreeを綺麗にすることができるが、少し扱いが難しいrebaseとGitTreeが乱雑になりがちだが、処理が簡単なmergeをご紹介しました。
主に企業で開発する場合よくbehindを解決してくださいと言われがちなので、ぜひ参考にしてみるといいと思います。

余談

私のバイト先でこういったお話がありました。

ローカルで作業する間はrebase等で整理してもいいかとおもいますが、あげた後にレビュー等を受けて変更したものrebaseしてしまうと壊れてしまいますのでマージがいいかと思います。

しかし、間違った方法で rebase を使うと、みんなから嫌われる可能性もあります。

プロジェクトによってはrebaseを使ってくださいと言われえる可能性があるので、その時は臨機応変に対応することが求められると思う。
特に、先輩によって、Rebase派とMerge派で別れてしまった場合は指示した人によって合わせると幸せになれると思います。

参考文献