GitHub フローのコンポーネント

完了

このユニットでは、GitHub フローの次のコンポーネントを確認します。

  • ブランチ
  • コミット
  • pull request
  • GitHub フロー

ブランチとは

前回のセクションでは、新しいファイルを作成しましたが、その過程で、リポジトリに新しいブランチも作成しました。

ブランチは、GitHub エクスペリエンスに不可欠な部分です。そこで、作業しているプロジェクト全体には影響を与えずに変更を加えることができるためです。

ブランチは、新しい機能や修正プログラムを試す安全な場所です。 間違えた場合は、変更を元に戻すか、追加の変更をプッシュして間違いを修正することができます。 ブランチをマージするまで、変更内容は既定のブランチでは更新されません。

Note

または、ターミナルで単純に git を使って新しいブランチを作成し、チェックアウトすることもできます。そのコマンドは次のようになります: git checkout -b newBranchName

コミットとは

前のユニットでお気付きかもしれませんが、リポジトリに新しいファイルを追加するには、コミットをプッシュする必要がありました。

コミットの概要を簡単に確認しましょう。

コミットは、ブランチ上の 1 つ以上のファイルに対する変更です。 コミットが作成されるたびに、一意の ID が割り当てられ、時間および共同作成者と共に追跡されます。 コミットにより、issue や pull request など、ファイルまたはリンク アイテムの履歴を確認しているユーザーに明確な監査証跡が提供されます。

A screenshot of a list of GitHub commits to a main branch.

Git リポジトリ内のファイルは、バージョン管理プロセスを経ていく過程で、いくつかの有効な状態になります。

Git リポジトリ内のファイルの主な状態は次のとおりです。

未追跡:ファイルがまだ Git リポジトリに含まれていない場合の初期状態です。 Git はその存在を認識していません。

追跡対象:追跡対象ファイルは、Git がアクティブに監視しているファイルです。 次のいずれかの下位状態になる場合があります。

  • 未変更:ファイルは追跡対象ですが、前回のコミット以降は変更されていません。
  • 変更済み:ファイルは前回のコミット以降に変更されていますが、これらの変更は次のコミット用にまだステージされていません。
  • ステージ済み:ファイルは変更され、その変更はステージング領域 (インデックスとも呼ばれます) に追加されました。 これらの変更はコミットする準備ができています。
  • コミット済み:ファイルはリポジトリのデータベース内にあります。 これは、ファイルの最新のコミット済みバージョンを表します。

これらの状態と下位状態は、チームと共同作業する際に、各コミットがプロジェクトのプロセス内のどこにあるかを把握するうえで重要です。

次に、pull request に進みましょう。

pull request とは

コミットとは何かがわかったので、pull request について確認しましょう。

pull requestとは、あるブランチからのコミットを別のブランチにマージする準備ができていることを伝えるために使用されるメカニズムです。

pull request を送信したチームのメンバーは、1 人以上のレビュー担当者に、コードを検証してマージを承認することを要求します。 これらのレビュー担当者は、変更に関するコメントを作成したり、独自の変更を追加したり、pull request自体を使用してさらなるディスカッションを行ったりできます。

変更内容が承認されたら (承認が必要な場合)、その pull request のソース ブランチ (比較ブランチ) はベース ブランチにマージされます。

A screenshot of a pull request and a comment within the pull request.

これですべての要素がわかったので、GitHub フローについて確認しましょう。

GitHub フロー

Screenshot showing a visual representation of the GitHub Flow in a linear format that includes a new branch, commits, pull request, and merging the changes back to main in that order.

GitHub フローは、安全な実験を行える軽量ワークフローとして定義できます。 ブランチ、pull request、マージを使って、新しいアイデアやチームとのコラボレーションをテストできます。

GitHub の基本がわかったので、GitHub フローとそのコンポーネントを確認していきましょう。

  1. GitHub フローの最初のステップは、ブランチを作成して、作成する変更、機能、修正がメイン ブランチに影響しないようにすることです。
  2. 2 番目のステップは、変更を加えることです。 機能ブランチに変更内容を配置してから、メイン ブランチにマージすることをお勧めします。 そうすることで、運用環境で変更内容が有効であることを保証できます。
  3. 3 番目のステップは、pull request を作成してコラボレーターにフィードバックを求めることです。 pull request のレビューは非常に重要なため、一部のリポジトリでは、pull request をマージする前に承認レビューが必要になります。
  4. 4 番目のステップは、コラボレーターからのフィードバックを確認して実装することです。
  5. 変更内容に問題がないことを確認できたら、5 番目のステップは、pull request の承認を受け、メイン ブランチにマージすることです。
  6. 最後の 6 番目のステップは、ブランチを削除することです。 ブランチを削除することで、そのブランチでの作業が完了したことを示し、自分や他のメンバーが誤って古いブランチを使わないようにすることができます。

GitHub フローのサイクルは以上になります。

次のセクションに進みましょう。次は、issue とディスカッションの違いについて説明します。