pull request とは

完了

ここでは、まず、次の作業を行います。

• ブランチと、pull request にとってのブランチの重要性を確認する。
• pull request とは何かを定義する。
• pull request の作成、pull request の状態の確認、pull request のマージを行う方法について説明します。

ブランチ

最初に、ブランチとは何か、開発者にとってのブランチの重要性、ブランチと pull request の関連性を定義します。

ブランチは分離されたワークスペースであり、ここでは、リポジトリ内の他のユーザーに影響を与えることなく作業を開発できます。 ブランチを使用すると、機能の開発、バグの修正、リポジトリ内の包含領域での新しいアイデアの安全な実験を行うことができます。

開発者が独立したブランチで作業することは、最新のソフトウェア開発では一般的な概念です。 開発者は、独自のブランチを持つことで、"コミット" と呼ばれる変更を行うことができ、それらのコミットが、独自のブランチで作業している他の開発者に与える影響を心配する必要はありません。

ブランチのマージ

各開発者が個別のブランチで作業することは個人の生産性にとっては非常に有効ですが、新たな課題が生じます。 ある時点で、各開発者のブランチを main などの共通のブランチにマージする必要があります。 プロジェクトの規模が拡大するにつれて、多くのマージが必要になる可能性があり、各マージを追跡してレビューすることがますます重要になります。 プロジェクトに対する複数の変更を追跡する必要がある場合に登場するのが、pull request です。

pull request とは

pull request は、ブランチの変更を文書化し、開発者のブランチからの変更をベース (メイン) ブランチにマージする準備ができていることを伝える方法です。 pull request を使用すると、提案された変更を関係者がレビューして議論する機会が与えられ、ベース ブランチ内のコードは、可能な限り高い品質を維持することが保証されます。

2 つのブランチをマージするには、それらが相互に異なっている必要があります。

• "比較" ブランチは、開発者独自のブランチであり、加えられた特定の変更が含まれています。
• "ベース" ブランチ ("メイン" ブランチ とも呼ばれます) は、マージ先となるブランチであり、ここに変更をマージする必要があります。

"比較" の最も一般的な用途は、新しい pull request を開始するときなどにブランチを比較することです。 新しい pull request を開始すると、常にブランチ比較ビューが表示されます。

pull request を作成する

ここで、pull request の作成方法を確認することにしましょう。

1. GitHub.com で、リポジトリのメイン ページに移動します。

2. [ブランチ] メニューで、コミットが含まれているブランチを選択します。

   

3. ファイルの一覧の上にある黄色のバナーで、[比較と pull request] ボタンを選択して、関連付けられたブランチの pull request を作成します。

   

4. [ベース ブランチ] ドロップダウン メニューで、変更をマージするブランチを選択します。 次に、[ブランチの比較] ドロップダウン メニューを選択して、変更を加えたトピック ブランチを選択します。

5. pull request のタイトルと説明を入力します。

6. レビューの準備ができている pull request を作成するには、[pull request の作成] ボタンを選択します。 ドラフト pull request を作成するには、ドロップダウンを選択し、[ドラフト pull request の作成] を選択し、[ドラフト pull request] を選択します。

pull request の状態

次に、pull request のさまざまな状態を確認することにしましょう。

• ドラフト pull request - pull request を作成するときに、レビューの準備ができている pull request を作成するか、"ドラフト" pull request を作成するかを選択できます。 ドラフト状態の pull request をマージすることはできません。コード所有者に対して、ドラフト pull request のレビューは自動的に要求されません。

• 開かれた pull request - 開かれた状態は、pull request がアクティブであり、ベース ブランチにまだマージされていないことを意味します。 この状態でも、コミットを作成し、変更の可能性についてコラボレーターと話し合い、レビューすることができます。

• 閉じられた pull request - pull request をベース (メイン) ブランチにマージしないで閉じることを選択できます。 このオプションは、ブランチで変更が提案されたがその必要がなくなった場合、または別のソリューションが別のブランチで提案された場合に便利です。

• マージ済み pull request - マージ済み pull request の状態は、比較ブランチからの更新とコミットがベース ブランチと組み合わされたことを意味します。 リポジトリに対してプッシュアクセスを持つユーザなら誰でもマージを実行できます。

pull requestをマージする

1. リポジトリ名の下にある [pull request] を選択します。

   

2. [pull request] のリストで、マージする pull request を選択します。

3. pull request 一番下までスクロールしてください。 リポジトリで有効なマージオプションに応じて、以下の操作が可能です:

   • [pull request のマージ] ボタンを選択すると、すべてのコミットがベース ブランチにマージされます。 [pull request のマージ] オプションが表示されない場合は、マージ ドロップダウン メニューで [マージ コミットの作成] オプションを選択し、[マージ コミットの作成] ボタンを選択します。

     

   • [スカッシュとマージ] を使用すると、すべてのコミットを 1 つに結合できます。 このオプションは、リポジトリ履歴の読みやすさを向上し、整理するのに役立ちます。 [スカッシュとマージ] オプションを選択し、[スカッシュとマージ] ボタンを選択します。

   • [リベースとマージ] オプションを使用すると、マージ コミットなしでコミットを作成できます。 このオプションにより、線形のプロジェクト履歴を保持してマージをスキップできます。 マージ ドロップダウン メニューを選択し、[リベースとマージ] オプションを選択し、[リベースとマージ] ボタンを選択します。

4. プロンプトが表示されたら、コミット メッセージを入力するか、既定のメッセージを受け入れます。

5. GitHub.com 上の自分のアカウントに複数のメール アドレスが関連付けられている場合、メール アドレス ドロップダウン メニューを選択し、Git 作成者のメール アドレスとして使用するメール アドレスを選択します。 このドロップダウン メニューには、確認済みのメール アドレスのみが表示されます。 メール アドレスのプライバシーを有効にした場合、no-reply GitHub メールがコミット作成者の既定のメール アドレスになります。

   

6. [マージの確認]、[スカッシュとマージの確認]、または [リベースとマージの確認] を選択します。

7. 必要に応じて、比較ブランチを削除して、リポジトリ内のブランチの一覧を整理できます。

次に、確認した内容を使用して、実際の例に適用する演習を行います。