それでは、「（変更の）包含要求」とは正確に何ですか（プル要求を翻訳した方法です）。 githubの公式ドキュメントには次のように書かれています：
プルリクエストを使用すると、GitHubリポジトリに投稿した変更について他のユーザーに伝えることができます。 プルリクエストが送信されると、関係者は変更を確認し、可能な編集について話し合い、必要に応じて補完的なコミットを追加します。
自分の言語で話す：プルリクエストを送信することにより、元のリポジトリの作成者（およびすべての関心のある人）に次のように言います。
共同開発モデルについて少し
GitHubでは、2つの共同開発モデルが人気があります。
- Fork + Pullモデルを使用すると、元のリポジトリにアクセスしなくても、誰でも既存のリポジトリをフォークし、変更を自分のフォークにマージできます。 次に、所有者が変更を元のリポジトリに含める必要があります。 このモデルは、新しい貢献者の移動回数を減らし、オープンソースプロジェクトで人気があります。これは、人々が単一の調整なしで独立して作業できるようにするためです。
- 共有リポジトリモデルは、閉じられたプロジェクトに取り組んでいる小さなチームや組織の間でより一般的です。 チームの全員が1つの共通リポジトリへの「書き込み」アクセス権を持ち、トピックブランチを使用して変更を分離します。
プル要求は、プロジェクトメンテナー（つまり、元のリポジトリの所有者）にリポジトリのコピーの変更を通知する方法を提供するため、Fork + Pullモデルで特に役立ちます。 ただし、これらは一般的なリポジトリモデルでも役立ちます。通常は、メインの開発ブランチに含める前に、コードの修正や議論を開始するために使用されます。
リポジトリのコピーを作成する
最初の開発モデルを考えると、作業を実行する元のリポジトリの独自のコピーと、元のリポジトリの作成者に提供される変更が必要です。
ガイドの一部として、 octocatユーザーのSpoon-Knife リポジトリで作業しており、ユーザー名がusernameであると想定します 。
これを行うのは非常に簡単です。リポジトリページに「フォーク」ボタンがあり、クリックする必要があります。
その後、このコピーをコンピューターに既に「プル」できます。
git clone git@github.com:username/Spoon-Knife.git
複製されたリポジトリには、元のリポジトリではなくGitHub上のコピーを指すoriginというリモートリポジトリへの1つのバインディングがあります。変更を追跡するには、たとえばアップストリームなどの別のバインディングを追加する必要があります。
cd Spoon-Knife git remote add upstream git://github.com/octocat/Spoon-Knife.git git fetch upstream
仕事をする
そのため、この時点で既にコードを編集してコミットすることができます。 変更を後で元のリポジトリに戻すために前の手順をすべて実行した場合は、開発の別のテーマブランチですべての作業を行うことを強くお勧めします。 これの有用性は、プルリクエストを送信する段階で明らかになります。 それを機能と呼びましょう。
git checkout -b feature # , "feature"
さて、良いことをしてください（そしてそれをコミットで表現しましょう）。
作業（または作業の一部）が完了したら、GitHubのリポジトリのコピーに送信します。
git push origin feature # origin feature
チェックイン：プルリクエスト
それで、すべてが完了しました。 コードを作成しました。コードは、コンピューターとGitHubの両方の機能ブランチにあります。 元のリポジトリに「送信」するだけです。
GitHubのリポジトリのコピーのページに移動し、機能ブランチを選択して、プルリクエストボタンをクリックします。
次に、変更の名前と説明を入力できるプレビューページが表示されます（名前はマージコミットの説明に該当し、パブリックになります。これを覚えておいてください）。
プルリクエストにどのコミットが入ったかを確認できます。
また、プルリクエストのすべての変更の一般的な差分：
デフォルトでは、プルリクエストは、親リポジトリの最も頻繁に統合されたブランチに基づいて考慮されます。 この場合、ユーザー名/ Spoon-Knifeはoctocat / Spoon-Knifeからコピーされたため、プル要求はoctocat / Spoon-Knifeリポジトリのmasterブランチに基づいて考慮されます。 ほとんどの場合、これは正しいですが、そうでない場合は、「コミットの変更」ボタンをクリックします
ベースブランチとソースブランチを選択するためのフォームが表示されます。
左側で、親リポジトリの変更がどのブランチに流れるか、右側でリポジトリから取得される変更を選択します。 例：octocat / Spoon-Knife /右側のマスター、ユーザー名/ Spoon-Knife /左側の機能。 ここでは、ブランチだけでなく、対応するリポジトリの個々のコミットのタグとIDも指定できます。
重要 ：変更をアップロードするブランチを「親」リポジトリの所有者と手配します（彼はこれをREADMEで記述できます）
ベースリポジトリを変更すると、プルリクエスト通知を受信するユーザーのリストも変更されます。 ベースリポジトリに「書き込む」権利を持っている人は誰でも、次回のアクセス時にメインのGitHubで通知を受け取り、通知を受け取ります。
コミットリストが満たされたら、[コミット範囲の更新]ボタンをクリックします。
名前と説明を入力し、プルリクエストに入ったファイルのコミットと変更のリストを再確認したら、[プルリクエストの送信]ボタンをクリックします。 プルリクエストがすぐに作成されます。
次は？
プルリクエストを追跡します。 人々がコメントすること、メンテナが言うこと、あなたのプルリクエストが受け入れるかどうか。
覚えておいて、プルに行くすべての変更は別のブランチに保持すべきだと言ったのですか？ したがって、主な利便性：コミットを既存のプルリクエストにいつでも追加でき、リポジトリのこのブランチに追加するだけです（はい、プルリクエストでソースブランチとして機能を指定する場合は
git push origin feature
） ）
プルリクエストを表示すると、名前、説明、およびコミットに加えて、次も表示されます。
- プルリクエストに残されたコメント。
- プルリクエストブランチに追加された追加のコミット。
- プルリクエストに含まれるコミットのいずれかに残された変更された行またはファイルに対するコメント。
プルリクエストのコメントでは、Markdownを使用できます。つまり、画像を挿入し、Markdownでサポートされているすべてのフォーマットを使用できます。
プルリクエストが受け入れられたら、変更をリポジトリにマージすることを忘れないでください（不要になった場合は削除してください）。
git checkout master git pull upstream master git push origin master
開発が実行されたブランチを削除することもできます。
git branch -d feature # git push origin :feature #
作業に時間がかかり、元のリポジトリがなんとか前進した場合はどうすればよいですか？
元のリポジトリから自分に変更をプッシュするだけです。
git checkout master git pull upstream master git checkout feature git merge master
ただし、元のリポジトリの所有者、あるいはあなたでさえ、hezhコミットやプルのコミットリスト内のマスターからのコミットの存在を好まないでしょう。 この場合、git rebaseを使用する必要があります。
git checkout master git pull upstream master git checkout feature git rebase master #
リベースの仕組みについては、 公式ガイドをご覧ください 。 非常に理解しやすいイラストもあります。 GitHubヘルプに関する記事もあります。
注意： git rebaseはコミットのIDを変更することに注意してください！ したがって、 これらのコミットが公開される前に、このコマンドを使用したすべてのアクションはローカルリポジトリでのみ実行する必要があります 。 githubにプッシュする前に。
あなたがホストの場合：プルリクエストを受け入れる方法
プルリクエストがすべての条件を満たしている場合、ターゲットリポジトリへの「書き込み」権限を持つ（つまりプッシュできる）人は、多くの方法のいずれかでプルリクエストを受け入れる必要があります。 最も一般的な3つの方法を以下に説明します。
自動マージ
多くの場合、変更をプッシュし、マージコミットを作成し、プルリクエストを閉じる緑色の大きな[プルリクエストをマージ]ボタンを使用して、githubにプルリクエストを自動的に受け入れるように依頼できます。
詳細については、このhabratopike： GitHubの[マージ]ボタンを参照してください 。
取得とマージ（ダウンロードとマージ）
変更を注入する主な方法。 リモートを追加して、プルリクエストを送信した人のリポジトリに移動し、このリポジトリから変更をダウンロードし、目的のブランチをマージし、競合を修正し、更新されたブランチを元のリポジトリにアップロードします。
git checkout master git remote add username git://github.com/username/Spoon-Knife.git git fetch username git merge username/feature git push origin master
パッチ適用
前の方法は、チームで作業するとき、または同じ人々のグループからの変更を常に受け入れるときにうまく機能します。 別の方法は、git-amを使用する場合の単一のケースでわずかに高速です。
各リクエストプルプールには独自の.patch URLがあり、そこからテキストパッチをダウンロードしてgit-amコマンドにフィードできます。
git checkout master curl https://github.com/octocat/Spoon-Knife/pull/50.patch | git am git push origin master
プルリクエストを閉じる
プルリクエストは、要求されたコミットが宛先リポジトリに注がれると自動的に閉じられます。 この場合、プルリクエストが受け入れられてメインブランチに投入されたことをすべての開発参加者に通知するイベントが生成されます。
プルリクエストが拒否された場合は、プルリクエストを手動で閉じることもできます。 git-cherry-pickまたはマージの事実を検出できない別のメカニズム（マージ）を使用して変更が受け入れられた場合、これが必要になることがあります。
結論の代わりに
このガイドが、多くのオープンソース（およびその他の）プロジェクトの改善に役立つことを願っています。
Habrahabrに長い時間を費やしましたが、これが私の最初のトピックです。 PMで報告するか、私がしたすべての欠点についてのコメントで報告してください。 修正します。
このような便利で無料のオープンソースサービスを提供してくれたGitHub開発チームと同様に、記事の公開に協力してくれたAntiarchitectと他のhabruzersに感謝します。