☰

「リモート追跡ブランチ 'origin/develop' をdevelopにマージする」のはなぜですか? 質問する

tag-icon • tag-icon git branching-and-merging git-merge git-remote
「リモート追跡ブランチ 'origin/develop' をdevelopにマージする」のはなぜですか? 質問する

私の組織では、次のメッセージでコミットを行っているのは私だけです。

リモート追跡ブランチ「origin/develop」をdevelopにマージする

何をすればこのような症状が出るのかは分かりませんが、やめたいと思います。

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

ベストアンサー1

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、 refgit remote update -pが自動的に削除されますorigin/foo。

  • git merge --ff-only @{u}@{u}ローカル ブランチをアップストリーム ブランチに「高速転送」できる場合 (つまり、分岐していない場合) にのみ、アップストリーム ブランチ (引数) をローカル ブランチにマージするように Git に指示します。

  • git rebase -p @{u}作成済みだがまだプッシュしていないコミットをアップストリーム ブランチの上に効果的に移動することで、避けたい無駄なマージ コミットを作成する必要がなくなります。これにより開発履歴の直線性が向上し、レビューが容易になります。

    オプション-pは、Git にマージを保持するように指示します。これにより、Git はリベースされるコミットを線形化しません。これは、たとえば機能ブランチを にマージした場合に重要ですmaster。 がない場合、機能ブランチのすべてのコミットは、 による線形化の一環として-pに複製されます。これにより、開発履歴の確認が容易になるのではなく、困難になります。mastergit 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}'

Now all you need to do to bring your branch up to date is to run:

git up

instead of git pull. If you get an error because your local branch has diverged from the upstream branch, that's your cue to rebase.

Why not git pull --rebase?

Running git pull --rebase is equivalent to running git fetch followed by git rebase. This attempts to fast-forward to the new upstream commits, but if that's not possible then it will rebase your local commits onto the new upstream commits. This is usually OK, but be careful:

  • Rebase is an advanced topic, and you should understand the implications before rebasing.
  • git pull --rebase does not give you an opportunity to examine the commits before incorporating them. Depending on what changed upstream, it's quite possible that rebase is the wrong operation—a rebase --onto, merge, reset, or push -f might be more appropriate than a plain rebase.
  • It is not (currently) possible to pass --preserve-merges to the rebase operation, so any intentional merge of a feature branch will be linearized, replaying (and thus duplicating) all of the feature branch commits.

"Fixing" an existing merge commit created by git pull

If you haven't yet pushed a merge commit created by git pull, you can rebase out the merge commit. Assuming you haven't made any intentional merges (e.g., merging an already-pushed feature branch into your current branch), the following should do it:

git rebase @{u}

The above command tells Git to select all of the non-merge commits reachable from HEAD (the current commit), minus all the commits reachable from @{u} (which is shorthand for "the upstream branch", i.e., origin/master if HEAD is master), replay (cherry-pick) them on top of the upstream branch, and then move the current branch reference to point to the result of replaying the commits. This effectively moves the non-merge commits onto the most recent upstream commit, which eliminates the merge created by git pull.

If you have an intentional merge commit, you don't want to run git rebase @{u} because it will replay everything from the other branch. Dealing with this case is substantially more complicated, which is why it's good to use git up and avoid git pull altogether. You'll probably have to use reset to undo the merge created by pull and then do git rebase -p @{u}. The -p argument to git rebase hasn't worked reliably for me, so you might end up having to use reset to undo the intentional merge, update your local branch to @{u}, and then redo the intentional merge (which is a pain if there were a lot of hairy merge conflicts).

おすすめ記事