git pull と git pull --rebase の使い分け

結論

そのブランチが個人作業用かどうかで使い分ける

• 個人の作業ブランチの場合
  • git pull --rebaseを使う
  • 理由：不要なコミット履歴（マージ）を作らない様にするため
• 複数人で作業するブランチの場合
  • git pullを使う
  • 理由：git push --forceによって他の作業者に影響が出る可能性があるため

一般的な流れの例

1. masterブランチから feature_hogeブランチを切る
2. feature_hogeブランチで作業をする
3. feature_hogeブランチでgit pull --rebase origin masterを実施した後、git push origin feature_hogeを実施する
4. feature_hogeブランチからmasterブランチへのプルリクエストを作成する

そもそも

git pull は以下2つの操作を1つのステップで実行するもの

git fetch

git merge

git pull --rebase は以下2つの操作を1つのステップで実行するもの

git fetch

git rebase

git rebase とは

• あるブランチの変更を別のブランチの上に「再適用（rebase）」する
  • 現在のブランチのコミットを一時的に取り除き、ベースとなるブランチ（例えば、masterブランチ）の最新の変更を現在のブランチに適用した後、先ほど取り除いたコミットを新たに適用する
• すなわち、コミット履歴が改変される可能性があるということ
  • その場合、git push --forceを使用する必要がある

具体例

• 以下の様なブランチ状況で、自分がfeature_fizzで作業をしていることとする

master
├ feature_fizz
└ feature_buzz

• feature_fizzをmasterにマージしたい時
  • 既にfeature_buzzの変更がmasterに取り込まれている
    • → まずはmasterの変更をfeature_fizzに取り込む必要がある

git pull を利用する場合

git pull origin master

• この場合、不要なマージコミットが履歴として残ってしまう

git push origin feature_fizz

git pull --rebase を利用する場合

git pull --rebase origin master

• rebase操作により、不要なマージコミットが生成されることがない
• コミット履歴が一本の直線のように見えるようになり、よりクリーンで読みやすい履歴を維持することができる

git push --force origin feature_fizz

• コミット履歴を改変したので、push時にforceオプションが必要になる

以上から、冒頭の結論になる。