git pullおそらくコミットを作成しています。ローカルコミットを行ってから実行した場合git pull他の誰かがリポジトリにコミットをプッシュした後に、Gitは他の開発者のコミットをダウンロードして、ローカルブランチにマージします。
これらのマージコミットを将来的に回避する方法
git pull --rebase将来的にこれが発生するのを防ぐために使用することもできますが、リベースは危険を伴うため、完全に回避することをお勧めしpullます。
代わりに、次の使用パターンに従うことをお勧めします。
# download the latest commits
git remote update -p
# update the local branch
git merge --ff-only @{u}
# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}
説明
git remote update -pリモートリポジトリのすべてのコミットをダウンロードし、リモート追跡ブランチを更新します（例：）origin/master。作業ディレクトリ、インデックス、ローカルブランチには影響しません。
-p引数プルーンは上流の枝を削除しました。したがって、fooブランチがoriginリポジトリで削除された場合、git remote update -pは自動的にorigin/foo参照を削除します。
git merge --ff-only @{u}アップストリームブランチ（@{u}引数）をローカルブランチにマージするようにGitに指示しますが、ローカルブランチをアップストリームブランチに「高速転送」できる場合（つまり、分岐していない場合）。
git rebase -p @{u}作成したコミットを効果的に移動しますが、まだ上流のブランチの上にプッシュしていないため、回避しようとしている愚かなマージコミットを作成する必要がなくなります。これにより、開発履歴の直線性が向上し、確認しやすくなります。
この-pオプションは、マージを保持するようにGitに指示します。これにより、Gitがリベースされるコミットを線形化できなくなります。これは、たとえば、機能ブランチをにマージした場合に重要ですmaster。がなければ-p、機能ブランチでのすべてのコミットは、masterによる線形化の一部として複製されgit rebaseます。これは、開発履歴を確認することを難しくします。
注意： git rebase期待どおりに動作しない可能性があるため、プッシュする前に結果を確認してください。例えば：
git log --graph --oneline --decorate --date-order --color --boundary @{u}..
git pull --rebase次の理由により、このアプローチを優先します。
- 履歴を変更して組み込む前に、受信するアップストリームコミットを確認できます。
- 意図的なマージ（たとえば、すでにプッシュされた機能ブランチのへのマージ）をリベースする必要がある場合に、
-p（--preserve-merges）オプションを渡すことができます。git rebasemaster
略記： git up代わりにgit pull
上記を簡単に行うために、次のエイリアスを作成することをお勧めしupます。
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
ブランチを最新の状態にするために必要なのは、実行することだけです。
git up
の代わりにgit pull。ローカルブランチが上流のブランチから分岐したためにエラーが発生した場合、それはリベースの手掛かりです。
なんでgit pull --rebase？
実行すると、git pull --rebase実行するのと同じであるgit fetchが続きますgit rebase。これは新しいアップストリームコミットに早送りしようとしますが、それが不可能な場合は、ローカルコミットを新しいアップストリームコミットにリベースします。これは通常は問題ありませんが、注意してください。
- リベースは高度なトピックであり、リベースする前にその影響を理解する必要があります。
git pull --rebaseコミットを組み込む前にそれらを調べる機会をあなたに与えません。上流の変更内容に応じて、それはリベースが間違っ操作であることはかなり可能ですrebase --onto、merge、reset、またはpush -fプレーンよりも適切であるかもしれませんrebase。- （現在のところ）
--preserve-mergesリベース操作に渡すことはできません。そのため、機能ブランチの意図的なマージは線形化され、機能ブランチのコミットがすべて再生（つまり複製）されます。
によって作成された既存のマージコミットの「修正」 git pull
によって作成されたマージコミットをまだプッシュしていない場合は、マージコミットgit pullをリベースできます。意図的なマージ（たとえば、既にプッシュされた機能ブランチを現在のブランチにマージするなど）を行わなかったとすると、次のようにする必要があります。
git rebase @{u}
上記のコマンドは、非マージのすべてがから到達可能なコミットを選択することにGitに指示しますHEAD（現在のコミット）、マイナスのすべてのコミットから到達可能@{u}（すなわち、「上流分岐」の省略形であるorigin/master場合HEADであるmaster）、リプレイ（チェリーピックを）それらを上流ブランチの上に置き、現在のブランチ参照を移動して、コミットの再生結果を指すようにします。これにより、非マージコミットが最新のアップストリームコミットに効果的に移動し、によって作成されたマージが排除されgit pullます。
意図的なマージコミットがある場合git rebase @{u}、他のブランチからすべてを再生するため、実行する必要はありません。このケースの処理はかなり複雑です。git upそのため、使用してgit pull完全に回避することをお勧めします。resetによって作成されたマージを元に戻すためにを使用するpull必要がありますgit rebase -p @{u}。への-p議論git rebaseは私にとって確実に機能しなかったのでreset、意図的なマージを元に戻し、ローカルブランチをに更新してから@{u}、意図的なマージをやり直さなければならなくなる可能性があります（これは、毛深いマージが多かった場合の苦痛です）競合）。