GitHubに投げたプルリクをマージする3パターンを考察

2019, Oct 30

アジェンダ

• 結論
• 操作手順
• 解説
• 追記(2019/10/28)
• 注釈

まずはこの絵を覚えておいてほしいです。 順番は、merge->rebase の順番に実施しています。 これは後ほど解説します。

結論

git rebase で運用したい場合、push した後はローカルファイルを削除すること。

操作手順

長いですが、全手順です。 同じような事を繰り返しているので、画像の状態と同じ様になっているか都度確認していきましょう。

1. 適当な変更をして commit する
2. push してプルリクする
3. 「create a merge commit」を選択（Merge pull request）
4. 承認して master に merge する
5. merge したブランチを削除
6. ローカルで pull する
   • この段階で merge の画像の状態になっている
7. 適当な変更をして commit する
8. push してプルリクする
9. 「Rebase and merge」を選択（Rebase and merge）
10. 承認して master に merge する
11. merge したブランチを削除
12. ローカルで pull する
    • この段階で rebase の画像の状態になっている
13. 適当な変更をして commit する
14. push してプルリクする
15. 「Squash and merge」を選択（Squash and merge）
16. 承認して master に merge する
17. merge したブランチを削除
18. ローカルで pull する
    • この段階で squash の画像の状態になっている

解説

ぱっと見、rebase と squash の違いが分からないですね。 これは軽度の開発だと squash の意味がないから¹ですが、本格的な検証をするためのうまい例題が思いつかないので、実際に当たってみないと説明が難しいです。 これは TODO で管理しておきますー！

追記(2019/10/28)

なぜ git rebase をやめるべきかの意味をようやく理解しました。 個人開発だとこの問題もいうほど深刻ではないですが、大規模なチーム開発をすると途端にノイローゼになりそうな大きな問題になります。 git bisectを使ってテストスクリプトを自動で実施させて問題箇所を特定する、という使い方をすることで問題を特定できるのが、rebaseをしてしまうとどこでバグが混入したか特定できないため、とあります。 git bisectの使い方

私の方でもやってみて、検証結果がわかれば記事を起こそうと思います。 これはすごいわ！

注釈