4

フォークされた git リポジトリと元のリモート リポジトリの同期に関する多くの質問を見つけましたが、私の正確な問題には当てはまりませんでした。

アップストリームのリモート名でプロジェクトをフォークしたとしましょう。私のフォークの名前はoriginです。masterとdevのoriginを追跡するmasterとdevブランチがローカルにあります。

フォークされたレポに変更を加えない限り、オリジンでフォークされたレポをアップストリーム/マスターと同期できることはわかっています。

git checkout master
git pull upstream master
git push origin master

ここまでは順調ですね。しかし、今はローカルの開発ブランチで作業しており、完了したらそれをローカルのマスターにマージしたいと考えています。しかし、最初にローカル マスターをアップストリームの変更に合わせて最新の状態にします。

git checkout master
git pull upstream master
git push origin master

最初の質問: これは正しいですか? しかし、ローカルの開発ブランチはどうすればよいでしょうか? 更新したマスターでリベースしてからローカルマスターにマージするか、リベースせずにマージしてみますか? または、アップストリーム/マスターを時々プルして、ローカル開発者をアップストリーム/マスターと常に同期させておく必要がありますか?

これが達成されたら、私は

git push origin master

ローカルおよびoriginで、私のdevブランチを削除します。しかし、現在、私のマスター(ローカルおよびオリジン) は、ローカルdevによって行われた変更によってアップストリーム/マスターから逸脱しています。

2 番目の質問:アップストリーム/マスターとの同期を維持するための適切な方法は何ですか? 私はまだ単にやりますか

git checkout master
git pull upstream master
git push origin master

または、ここで他に推奨されるものはありますか (たとえば、何らかの形のリベース)? ブランチdevを再度作成した場合、最初の質問に適用したのと同じ戦略を再度適用しますか、それとも別の方法を適用しますか?

ご協力いただきありがとうございます！

4

1 に答える 1

5

質問1：

どちらでもいいと言う事です。私の経験では、通常、次のようなものがうまく機能します。

  • アップストリーム/マスターからローカル/マスターにマージするときは、ローカル/開発をリベースするのが理にかなっています。
  • master に変更を加えたときに dev をリベースすることで、dev を master にマージするときに必要なマージ/リベースのサイズを縮小できます。
  • master から dev への変更を常にリベースする限り、これは機能します

dev の作業が完了したら、もう一度リベースしてからマスターにマージするか、単にマスターに直接マージすることができます。マージの内容を示すために、マージ コミットのメッセージを変更することができます。

質問2：

アップストリームからマージする場合、ローカルまたはオリジンに異なる変更がない限り、マージは早送りされます。これは基本的に、git がアップストリームからのコミットをあなたが持っていたものの上に積み重ねるだけであることを意味し、競合などのマージはありません。

このため、リベースなどを行う必要はありません。前述のように、dev で何か作業をしている場合は、この時点で dev をリベースして最新の状態にすることをお勧めします。

アップストリームとは異なる変更を行った時点で、実際のマージが行われ、必要に応じてリベースを行うことができます。

リベースまたはマージ?

これは主にあなたとあなたがどのように働きたいか次第ですが、リベースを検討している場合は、それが歴史を変えることを覚えておいてください.

他の誰かが origin/master または origin/dev を使用していて、それをリベースした場合、彼らの作業を元にマージしようとすると、いくつかの問題が発生する可能性があります。したがって、通常、ブランチが複数の人によって使用されている場合は、マージを使用する必要があります。複数の人がブランチを使用している場合は、リベース (または履歴を変更するその他のもの) を使用しないでください。

于 2011-07-06T22:27:32.040 に答える