mergeとrebaseは両方とも異なるブランチの変更を統合するためのコマンドですが、統合の方針に違いがあります。
初期値としてmasterブランチとfeatureブランチがあり、両方のブランチが修正されている状態です。
git mergeの統合
# git checkout feature
# git rebase master
# git checkout master
# git merge featuremasterブランチからfeatureブランチをmergeした場合に、コミット4という新しいマージコミットが作成されます。
コミット4はコミット2とコミット3を親コミットとします。
mergeはブランチを破壊（削除）することがないので、既存のブランチは変更されません。
ただ、featureブランチに関係のないマージコミットが作成されて、履歴が複雑になります。
git rebaseの統合
# git checkout master
# git merge featuregit rebaseは、作業が完了したブランチを分岐元のブランチに戻すときに使う機能です。
rebaseコマンドは、masterブランチの変更（コミット2）がfeatureブランチに取り込まれて、featureブランチの起点が変更されて、コミット3´というコミットが作成されます。
この時に、コミット3というコミットが削除されて、コミット3´の親コミットがコミット2になります。
不必要なマージコミットが作成されることもなく、1直線に綺麗なコミット履歴を作ることができます。
コミット履歴（git log）が綺麗であれば、コンフリクトが生じにくくなります。
git rebaseでやってはいけないこと
GitHubにプッシュしたコミットは絶対にリベースしてはいけません。
コミット1の次のコミットがローカルリポジトリではコミット3、GitHubではコミット2とコミットの順が異なっています。
この状態では、GitHubにアップされている除法を優先して、push自体することができません。
但しこの状態でも、「git push -f」というコマンドであれば、pushすることができます。
しかし、履歴が壊れてしまいますので、「git push -f」は絶対に行ってはいけません。
rebaseとmergeのコンフリクトの違い
mergeよりもrebaseの方がコンフリクトの解決が複雑で難しくになります。
コミット2とコミット3、コミット4の1行がすべて異なる状態だとします。
mergeの場合は、コミット4の修正をすると、コンフリクトが解決して、mergeすることができます。
しかし、rebaseの場合は、コミット3とコミット4の2箇所でコンフリクトを解決しなければなりません。
rebaseとmergeのどちらを使うべきか？
チームの作業方針によって、rebaseとmergeを使い分けることになります。
作業の履歴を残す方針であればmergeを使い、履歴を綺麗に保つ方針であればrebaseを使います。