次にすべきことは、新しい機能を提供したり、独自の専用ブランチ（フォークにのみプッシュされます）の他のバグを修正したりすることです。
つまり、フォークはそのまま残りますが、フォーク内のブランチは行き来できます。
さらに貢献する予定がない場合は、フォークを削除することもできますが、「貢献するリポジトリ」の対応するエントリが削除されます。
それは簡単です：
- あなたの削除
fixブランチを（実際には、それが今、あなたのために削除され、あなたのフォーク上）（そして、あなたの地元のクローン化されたレポで：「を参照してください。ローカルとリモートの両方でGitのブランチを削除します」）
git pull upstream master（master修正が統合されたブランチの場合：マージは早送りになります）：この時点ではリベースは必要ありません。- 更新されたローカルの上に修正ブランチを再作成します
master（現在はからの最新のものを使用upstream master）。
ただし、将来のプルリクエストを送信する前に、必ず1つのステップを忘れないでください。
最初に現在のブランチ（fix）を上流の宛先ブランチからリベース
（upstreamあなたがフォークした元のレポである：githubのoriginと上流の違いは何ですかを参照してください）
元のリポジトリ（「アップストリーム」）に何かを送信する前に、作業が上記の元のリポジトリの最新のものに基づいていることを確認する必要があります（または、プルリクエストが適用されると、早送りマージが行われません。upstreamrepoに戻る）。
たとえば、「githubの共有リポジトリのプルリクエストを管理するワークフロー」を参照してください。
言い換えれば、upstreamあなたがものを修正するのに忙しい間、進化することができます（それに新しいコミットがプッシュされる）コミットが最新のと互換性があることを確認するには、アップストリームから最新の作業に加えて修正を再生する必要がありますupstream。
OP Santosh Kumarが尋ねるコメントで：
私はプルしupstreamてマスターにマージしましたが、何ですか？
最近のプルリクエスト以降に新しい修正を行っていない場合は、上記を参照してください（fix更新したの上に新しいブランチを削除して再作成しますmaster）。
プルリクエスト以降にさらに作業を行った場合upstream、新しいプルリクエストを作成する場合はマージしません。プルしてリベースします。
git pull --rebase upstream master
このようにして、新しいローカル作業はすべて、最新のupstream masterコミット（ローカルリポジトリでフェッチされた）の上に再生されますmaster。これが、将来のプル要求を統合するターゲットブランチであると想定します。
次に、ローカル作業を「origin」にプッシュできupstreamます。これは、GitHubの私のフォークです。
そして、GitHubのフォークから、upstreamマージの解決を必要とせずに新しいコミットを追加するだけであることを知って、安全にプルリクエストを行うことができます。これらの新しいコミットをupstreamリポジトリにマージすると、単純な早送りマージになります。
git pull --rebaseあなたをリベースしたいの上に枝を指定せずに（現在チェックアウト）fix分岐が機能しません。
それ（git pull --rebase）は言う：
You asked to pull from the remote '`upstream`', but did not specify a branch.
最後にマスターを追加する必要がありますか？そして、これは何をしますか？それは私のfixブランチを削除しますか？
はい、プルリクエストのターゲットとなるブランチを指定できます（例： ' master'）。
これはfixブランチを削除しませんmasterが、リポジトリでフェッチされたアップストリームの上でそれを再生します。
:)