[解決済み] なぜ「リモート追跡ブランチ 'origin/develop' を develop にマージする」のでしょうか?

質問

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

リモートトラッキングブランチ 'origin/develop' を develop にマージする

何をしたらそうなるのかわからないが、やめたい。

このコミットを生成するために私はどのようなコマンドを発行しているのでしょうか。また、このコミットを生成しないために私が使用すべき適切なコマンドは何でしょうか。

どのように解決するのですか？

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} は、Git に上流ブランチをマージするよう指示します ( @{u} ただし、ローカルブランチを上流ブランチに "早送りできる場合のみです (言い換えると、分岐していない場合です)。

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

  は -p オプションは、Git にマージを保持するよう指示します。 これは、Git がリベースされるコミットを線形化するのを防ぎます。 これは、たとえば機能ブランチを master . がなければ -p を実行すると、feature ブランチのすべてのコミットが master によって行われる線形化の一部として git rebase . これでは、開発履歴の確認が容易になるどころか、難しくなってしまいます。

  注意事項 : git rebase は期待通りの動作をしないことがあるので、押す前に結果を確認してください。 例えば

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

私は、この方法の方が git pull --rebase は、以下の理由からです。

• を可能にします。 受信した上流コミットを見る 履歴を修正する前に、その履歴を取り込むことができます。
• を渡すことができるようになります。 -p ( --preserve-merges ) オプションを git rebase 意図的にマージしたものをリベースする必要がある場合 (たとえば、すでにプッシュされている機能ブランチのマージで master ).

速記。 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 が間違った操作である可能性は十分にあります。 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} そして、意図的なマージをやり直します (これは、多くの毛深いマージの衝突があった場合には面倒です)。