web-dev-qa-db-ja.com

「リモート追跡ブランチ 'Origin / develop'を開発にマージする」のはなぜですか？

私は、組織内で次のメッセージをコミットしている唯一の人です。

リモート追跡ブランチ「Origin/develop」を開発にマージします

それらを引き起こすために私が何をしているかわからないが、私はやめたい。

このコミットを作成するためにどのコマンドを発行していますか？また、それを生成しないために使用すべき適切なコマンドは何ですか？

gitbranching-and-merginggit-mergegit-remote
112
Jordan Feldstein

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 refを削除します。

  • git merge --ff-only @{u}は、Gitにローカルブランチにアップストリームブランチ（@{u}引数）をマージするように指示しますが、ローカルブランチをアップストリームブランチに「早送り」できる場合（つまり、そうでない場合） t発散）。

  • git rebase -p @{u}は、作成したコミットを効果的に移動しますが、まだ上流ブランチの上にプッシュしていません。これにより、回避しようとしている愚かなマージコミットを作成する必要がなくなります。これにより、開発履歴の線形性が向上し、レビューが容易になります。

    -pオプションは、Gitにマージを保持するよう指示します。これにより、Gitがリベースされるコミットを線形化できなくなります。これは、たとえば、機能ブランチをmasterにマージした場合に重要です。 -pがなければ、git rebaseによって行われた線形化の一部として、機能ブランチのすべてのコミットがmasterに複製されます。これにより、開発履歴を確認するのが難しくなり、簡単になりません。

    注意してください：git rebaseは期待どおりに動作しない可能性があるため、プッシュする前に結果を確認してください。例えば：

    git log --graph --oneline --decorate --date-order --color --boundary @{u}..

次の理由から、git pull --rebaseよりもこのアプローチの方が好きです。

  • 履歴を修正して組み込む前に、 アップストリームのコミットを見ることができます 。
  • 意図的なマージ（たとえば、既にプッシュされた機能ブランチのmasterへのマージ）をリベースする必要がある場合に、-p（--preserve-merges）オプションをgit rebaseに渡すことができます。

略記：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/masterHEADがmasterの場合、それらを上流ブランチ上で再生（チェリーピック）し、現在のブランチ参照を移動してコミットの再生結果を指すようにします。これにより、非マージコミットが最新のアップストリームコミットに効果的に移動され、git pullによって作成されたマージが排除されます。

意図的なマージコミットがある場合、git rebase @{u}を実行したくないのは、他のブランチからすべてを再生するためです。このケースの処理はかなり複雑です。そのため、git upを使用し、git pullを完全に避けるのが良い理由です。おそらくresetを使用して、pullによって作成されたマージを元に戻し、git rebase -p @{u}を実行する必要があります。 -pへのgit rebase引数は確実に機能しなかったので、意図的にマージを元に戻し、ローカルブランチを@{u}に更新してからやり直すには、resetを使用する必要があります意図的なマージ（多くの毛深いマージの競合があった場合、これは苦痛です）。

184
Richard Hansen
git fetch
git rebase Origin/master

それはそれを行う必要があります。または、プルを使い続けたい場合

git pull --rebase

また、設定でそのブランチを自動的にリベースするようにセットアップしたり、作成する他の将来の追跡ブランチに対して自動的にそのようなセットアップを行うこともできます。その後、使用するだけに戻ることができます

git pull

詳細については、このページの「マージではなくリベースでプル」セクションをご覧ください。

http://mislav.uniqpath.com/2010/07/git-tips/

17
Adam Dymitruk