147

組織内で次のメッセージでコミットしているのは私だけです。

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

それらを引き起こすために私が何をしているのかわかりませんが、やめたいと思います。

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

4

3 に答える 3

228

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ブランチが削除された場合、 refは自動的に削除されます。origingit remote update -porigin/foo

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

  • 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 fetchgit rebase

  • リベースは高度なトピックであり、リベースする前にその影響を理解する必要があります。
  • git pull --rebaseコミットを組み込む前に、コミットを調べる機会はありません。アップストリームで何が変更されたかによっては、リベースが間違った操作であるrebase --onto可能性があります。 merge、、、、resetまたはpush -fプレーンよりも適切な場合がありますrebase。
  • （現在）--preserve-mergesリベース操作に渡すことはできないため、機能ブランチの意図的なマージは線形化され、すべての機能ブランチのコミットが再生（したがって複製）されます。

によって作成された既存のマージコミットを「修正」するgit pull

によって作成されたマージコミットをまだプッシュしていない場合は、マージコミットgit pullをリベースできます。意図的なマージを行っていない場合（たとえば、すでにプッシュされている機能ブランチを現在のブランチにマージする場合）、次のようにする必要があります。

git rebase @{u}

上記のコマンドは、（現在のコミット）から到達可能なすべての非マージコミットから、（「アップストリームブランチ」の省略形、つまり、の場合）からHEAD到達可能なすべてのコミットを差し引いたものを選択するようにGitに指示します。 ）それらをアップストリームブランチの上に配置し、現在のブランチ参照を移動して、コミットの再生結果をポイントします。これにより、非マージコミットが最新のアップストリームコミットに効果的に移動し、によって作成されたマージが排除されます。@{u}origin/masterHEADmastergit pull

git rebase @{u}意図的なマージコミットがある場合は、他のブランチからすべてを再生するため、実行したくありません。このケースへの対処はかなり複雑です。そのため、使用して完全git upに回避することをお勧めします。によって作成されたマージを元に戻すには、git pullおそらくを使用してから実行する必要があります。の議論は私にとって確実に機能しなかったので、意図的なマージを元に戻し、ローカルブランチをに更新してから、意図的なマージをやり直す必要があるかもしれません（これは、ヘアリーマージがたくさんあった場合は苦痛です）競合）。resetpullgit rebase -p @{u}-pgit rebasereset@{u}

于 2011-06-20T04:55:44.147 に答える
21 
git fetch
git rebase origin/master

それはそれをする必要があります。または、引き続きプルを使用する場合

git pull --rebase

構成内でそのブランチをセットアップして自動的にリベースすることも、将来作成する他のトラッキングブランチ用にそのように自動的にセットアップすることもできます。その後、使用するだけに戻ることができます

git pull

これについては、このページの「マージではなくリベースでプルする」セクションで詳しく説明します。

https://mislav.net/2010/07/git-tips/

于 2011-06-20T05:59:22.857 に答える
0

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

これは、origin / development（リモート変更）をdevelop（ローカル変更）にマージしたgit pullであり、コードが失われるなどの理由で多くの問題が発生しました。

これで、ワークフローはgit pullのマージに関する問題を防ぎ、物事をシンプルに保ちます。基本的にはリベースのようなものですが、ブランチをマージすることで、最も基本的なGUIで簡単に実行できます。他の変更は常にあなたのものにマージされるので、競合が発生した場合は、変更した行に影響するものだけを修正します！そして、変更のみが最終コミットに表示されます。

  1. チェックアウトとプル開発
  2. 開発から機能ブランチXを作成します
  3. Xにあなたの仕事をしなさい
  4. 可能な着信変更のチェックアウトとプル開発を取得するには
  5. リモート変更があった場合は、Xにマージ開発します
  6. 競合がある場合は解決します
  7. 5または6を実行した場合は、4に戻ります
  8. Xを開発にマージ
  9. プッシュ開発

ええ、それは少し面倒なように見えます、ブランチを変更する、引っ張る、そしてすべて。ただし、rebase docを見ると、共有ブランチで使用しないように警告されています。したがって、同じXブランチを作成してから、git fetchorigindevelopとgitrebaseorigin / developmentを作成し、そのリベースされたXブランチを共有ブランチdevelopにマージして戻す必要があるため、同じ量の作業が必要になります。

通常、ステップ5でリモート変更があった場合、特にステップ6で競合が発生した場合は、再度テストする必要があり、時間がかかるため、ステップ4に戻ります。ステップ8と9を実行している競合状態があります。しかし、それは実際には他の誰かがあなたの直前にプッシュするコーナーケースです。

于 2021-07-08T20:58:39.900 に答える