2

git rebase の競合に問題がありますが、2 つのリモート リポジトリを使用している場合のみです。ワークフローは次のとおりです。

  1. 仕事する...
  2. 専念
  3. pull -r ステージング マスター

これはうまくいきます。競合があれば解決できます。

次に、本番リモートリポジトリで作業するときに問題が発生します。私は生産を推進しているのは私だけです。

  1. git pull -r production (何らかの理由で本番環境にプッシュする前にこれを行う必要があります...早送りプッシュする必要があるため、理由はわかりません。)
  2. git push プロダクション
  3. git pull -r staging (リポジトリを更新するため)

ここでは、私が作業していないファイルであらゆる種類のマージ競合が発生します。

競合は次のようになります。

<<<<<<< HEAD
  here's some code...
=======
  more code...
>>>>>>> commit foo

それで、ここに質問があります：

  1. 私だけが本番環境にプッシュしているのに、なぜ本番環境からプルする必要があるのですか?
  2. 既にコミットされていて、変更していないコードでマージの競合が発生するのはなぜですか?
  3. どのコミットを選択しますか? HEAD または commit foo
  4. それが起こらないようにするためのより良いプロセスは何ですか？
4

1 に答える 1

1

これは、2 つの別々のリモート リポジトリに対して実行したことの直接的な副作用です。pull --rebase取得したばかりのリモート HEAD の上に既存のローカル コミットをリベースし、2 番目のリモート リポジトリには存在しない新しい HEAD SHA1 を確実に作成します。 (prod例えば)

「 git pull --rebase を使用する必要があるのはいつですか?」で説明されているように、同じリモート リポジトリの同じブランチで共同作業しているときにpull --rebase、どこにもプッシュしたことがないコミットに使用できます。

しかし、2 つのリモート リポジトリがある場合は、「いつgit pull --rebase私がトラブルに巻き込まれるのか?」に示されているように、最初のプッシュの後は避ける必要があります。

このトピックの詳細については、「実際に機能する git ブランチ モデルは?」を参照してください。

于 2012-10-05T05:30:58.367 に答える