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

完了

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

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

ブランチとは

最後のセクションでは、リポジトリに新しいファイルと新しいブランチを作成しました。

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

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

Note

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

コミットとは

前のユニットでは、コミットをプッシュすることで、新しいファイルをリポジトリに追加しました。 コミットの概要を簡単に確認しましょう。

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

メイン ブランチに対する GitHub コミットの一覧のスクリーンショット。

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

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

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

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

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

pull request とは

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

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

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

pull request と pull request 内のコメントのスクリーンショット。

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

GitHub フロー

GitHub フローの視覚的な表現を示すスクリーンショット。新しいブランチ、コミット、pull request、その順序でのメインへの変更のマージを含む行形式になっています。

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

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

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

GitHub フローのサイクルは以上です。

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