私はいつかgitを使い始めましたが、複雑さを完全には理解していません。私の基本的な質問はここに違いを見つけることですgit pullし、をgit pull --rebase追加しているので、--rebase非常に異なる何かをしていないようオプションを：ちょうどプルを行います。
違いを理解してください。
回答:
git pull= git fetch+ git merge上流ブランチの追跡に反対
git pull --rebase= git fetch+ git rebase上流ブランチの追跡に反対
あなたはどのように知りたい場合git mergeとgit rebase異なり、これを読んで。
git pull --rebaseと同じであるgit fetchとgit rebaseそれがどのように基本的ですが、それはありません正確に同じ意味。いくつかの違いがありますが、その一部をここで説明します。gitolite.com/git-pull--rebase
fetchですか？
時々、依存しているブランチをリベース/巻き戻しするアップストリームがあります。これは大きな問題になる可能性があります-ダウンストリームの場合、厄介な競合が発生します。
魔法は
git pull --rebase通常のgit pullは、大まかに言えば次のようなものです（これらの例ではすべて、originというリモートとfooというブランチを使用します）。
# assume current checked out branch is "foo" git fetch origin git merge origin/foo一見すると、git pull --rebaseがこれを行うと思うかもしれません：
git fetch origin git rebase origin/fooしかし、アップストリームのリベースに「つぶし」が含まれている場合（つまり、コミットのパッチIDが順序だけでなく変更された場合）は、役に立ちません。
つまり、git pull --rebaseはそれ以上のことを行う必要があります。ここでは、その機能と方法について説明します。
あなたの出発点はこれだとしましょう：
a---b---c---d---e (origin/foo) (also your local "foo")時が経ち、あなたは自分の "foo"の上にいくつかのコミットをしました：
a---b---c---d---e---p---q---r (foo)その間、反社会的な怒りの発作で、上流のメンテナーは彼の "foo"をリベースするだけでなく、スカッシュや2つも使用しました。彼のコミットチェーンは次のようになります。
a---b+c---d+e---f (origin/foo)この時点でgit pullを実行すると、混乱が生じます。git fetchでさえ; git rebase origin / fooはそれをカットしません。なぜなら、一方の側で「b」と「c」をコミットし、もう一方の側で「b + c」をコミットすると競合するためです。（同様に、d、e、およびd + eを使用）。
git pull --rebaseこの場合、何をしますか：git fetch origin git rebase --onto origin/foo e fooこれはあなたに与えます：
a---b+c---d+e---f---p'---q'---r' (foo)
それでも競合が発生する可能性がありますが、それらは真の競合（p / q / rとa / b + c / d + e / fの間）であり、b / cがb + cと競合することによる競合ではありません。
から取られた（そしてわずかに変更された）回答：http :
//gitolite.com/git-pull--rebase
a---b+c---d+e---f---p'---q'---r' (foo)リベースはハッシュを変更するので、最終結果をに変更したい場合があります。
A承認された上流のリポジトリにPRを送信しました。その後git pull --rebase、上流のレポに対して反対したときA'、プルされた上流のレポの上に新しいコミットを取得しませんでした。実際にはまったくA'存在しませんでした。これAはシステムに統合されたためですか？それとも、アップストリームと私のリベースバージョンに違いがなかったためですか？
git pull --rebaseます。しかし、この架空の状況で私を混乱させる1つのことは、上流のメンテナが、ローカルの開発者のリポジトリにすでに組み込まれているプロジェクト履歴を変更したことです。これは一般的に単に悪い習慣ではありませんか？彼がコミット/リライト履歴をスカッシュしたい場合は、これらのタイプの競合を回避するために、それを中央リポジトリに統合する前に行う必要があります。
ローカルブランチに2つのコミットがあるとします。
D---E master
/
A---B---C---F origin/master
「git pull」の後、次のようになります。
D--------E
/ \
A---B---C---F----G master, origin/master
「git pull --rebase」の後、マージポイントGはなくなります。DとEは異なるコミットになることに注意してください。
A---B---C---F---D'---E' master, origin/master
git rebaseしているのではないですか？しかし、我々は話しているgit pull --rebase。そして、それらは異なるものです。
衝突がない非常に単純な場合
以下も参照してください。
man git-pull
より正確には、git pullは指定されたパラメーターでgit fetchを実行し、git mergeを呼び出して、取得したブランチヘッドを現在のブランチにマージします。--rebaseを使用すると、git mergeではなくgit rebaseが実行されます。
参照：
いつgit pull --rebaseを使用すべきですか？
http://git-scm.com/book/en/Git-Branching-Rebasing
git sdd modified-file; git rebase --continueまたはマージ：git add modified-file; git commit;どこmodified-fileローカルファイルを手動で/ mergetool変更された
fetchですか？なぜ2つのrebaseフローを作成したのですか？1）git rebaseと2）git pull --rebase？
これはMergeとRebaseの違いを理解するために重要です。
リベースとは、変更が階層の最上位から下に向かって進む方法であり、マージとは、変更が上に戻る方法です。
詳細については、http：//www.derekgourlay.com/archives/428を参照してください。