github上のプロジェクトに貢献する、「マスターの上にプルリクエストをリベースする」方法

わかりましたので、github上のプロジェクトに貢献しています。githubの上のプロジェクトがあるupstreamgithubの上の私のフォークのレポがある、originと私のlocal私のコンピュータ上のレポ。

git checkout -b feature
# Working on feature
git commit -a -m 'only commit on feature'

次にプルリクエストを送信します

git push origin master

プルリクエストが確認され、無関係な変更を行う必要があります。他の誰かがコミットしてマージしますupstream/master

upstreamメンテナから「プルリクエストをマスターの上にリベースする」ように言われました

これは私の話です（法と秩序の効果音を挿入してください）。

私はプルリクエストに変更を加えていませんが、ブランチ機能でのコミットは同じです。

git checkout master
git fetch upstream
git checkout feature
git rebase master
=> "Current branch feature is up to date."
git push origin feature
=> "Everything up-to-date"

わかりません。私がupstream/masterプルリクエストをプッシュした後に誰かがコミットしてマージしたことを知っている場合、これはどのようにして可能origin/featureですか？

この状況で正しい手順を教えてください。

上流のリポジトリでのみフェッチを表示します。実際には、ローカルブランチは更新されません。それはあなたの知識を更新するだけですupstream。にリベースする前に、またはより単純ににリベースする前に、と同様upstream/masterにがに完全にマージされていることを確認する必要があります。mastergit pullmasterupstream/master

すなわち：

git checkout master
git pull upstream master
git checkout feature
git rebase master

または

git checkout feature
git rebase upstream/master

更新：

ローカルfeatureブランチを修正した後origin、プルリクエストの更新を完了するには、ブランチをプッシュして戻す必要があります。featureすでに一度プッシュpushしたので、リベースが履歴を変更するため、単純に再度実行することはできません。通常、「non-fast-forward」でプッシュが失敗した場合は、プルを実行してプッシュを解決しますが、プルは2つの分岐した履歴を結合するだけであり、これは明らかに望ましいことではありません。つまり、古い（リベース前）featureブランチが新しい（リベース後）ブランチと結合されます。あなたはしたい上書き origin/feature新の状態とfeature古いものの任意のレコードをダンプ、枝。つまり、早送りではありませんが、を使用してプッシュを強制的に実行する必要がありますgit push -f origin feature。注意：危険であり、コミットを失う可能性があります。ここでのように、rebase前のfeatureブランチにある古くて役に立たないコミットを意図的に削除したい場合に、何をしているのかが確実にわかっている場合にのみ使用してください。

上流のメンテナから「プルリクエストをマスターの上にリベースする」ように言われました

2016年9月以降、メンテナは自分でリベースをトリガーできることに注意してください。

「を参照してくださいリベースとマージプルリクエスト」

新しい「リベースとマージ」オプションを選択すると、プルリクエストのブランチからのコミットがベースブランチの先端にリベースされ、ベースブランチ自体がこの新しくリベースされたヘッドに高速転送されます。リベースでは、リベースされたコミットのコミッターが現在のユーザーに自動的に設定され、作成者情報はそのまま維持されます。プルリクエストのブランチは、この操作によって変更されません。

競合が原因でリベースを実行できない場合は、必要に応じて手動で解決できるようにお知らせします。