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

  • 8 分

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

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

GitHub Flow のコンポーネント

GitHub 固有のワークフローに入る前に、GitHub Flow が Git の基本的な概念に直接基づいて構築されることを理解しておくと役立ちます。

Git には、時間の経過と同時にコードの変更を追跡および管理するためのツールが用意されています。 GitHub は、ブランチ、コミット、プル要求、コラボレーション用のビジュアル インターフェイスなどの機能でこれらのツールを簡単に使用できるようにすることで、これに基づいています。 まず、これらの概念が GitHub でどのように機能するかを見てみましょう。

ブランチとは

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

ブランチは、GitHub エクスペリエンスの重要な部分です。 既定のブランチに影響を与えずに変更できます。

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

注

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

コミットとは

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

コミットは、ブランチ上の 1 つ以上のファイルに対する変更です。 各コミットは、コマンド ラインを介して行われるか、GitHub の Web インターフェイスで直接行われるかに関係なく、一意の ID、タイムスタンプ、および共同作成者によって追跡されます。 コミットにより、issue や pull request など、ファイルまたはリンク アイテムの履歴を確認しているユーザーに明確な監査証跡が提供されます。

次のコマンドを使用して、ターミナルで Git を使用してコミットを作成できます。

git commit -m "Add a helpful commit message"

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

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

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

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

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

これらの状態は、各ファイルの状態と、それがバージョン管理プロセス内のどこにあるかをチームが理解するのに役立ちます。

プル リクエストとは何ですか？

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

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

GitHub では、まだレビューの準備ができていない pull request を開くことができる Draft Pull Requests もサポートされています。

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

プルリクエストとその中のコメントのスクリーンショット。

ブランチ、コミット、プル要求がどのように機能するかを見てきたので、GitHub Flow でどのように連携するかを見てみましょう。

GitHub フロー

GitHub フローの視覚的な表現を示すスクリーンショット。新しいブランチ、コミット、プル要求、変更を main にマージする順序を含む線形形式です。

GitHub フローは、変更を安全に行って共有するのに役立つ簡単なワークフローです。 アイデアを試したり、ブランチ、プル要求、マージを使用してチームと共同作業を行うのに最適です。

注

GitHub フローは、いくつかの一般的なワークフローの 1 つです。 その他には、Git フローとトランクベースの開発が含まれます。

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

  1. 最初にブランチを作成して、変更、機能、修正がメイン ブランチに影響しないようにします。
  2. 次に、ブランチで更新を行います。 ワークフローでサポートされている場合は、マージする前に、このブランチから変更をデプロイしてテストできます。
  3. 次に、pull request を開いてフィードバックを招待し、レビューを開始します。
  4. 次に、コメントを確認し、チームのフィードバックに基づいて必要な更新を行います。
  5. 最後に、変更に自信が持てたら、承認を得て、pull request をメイン ブランチにマージします。
  6. その後、ブランチを削除してリポジトリをクリーンに保ち、古いブランチを使用しないようにします。

Git フロー

機能ブランチ、開発、リリース ブランチ、修正プログラム、マスターの並列レーンを含む Git フロー ワークフローを示す図。機能を開発にマージする方法、開発からリリース ブランチを作成する方法、修正プログラムをマスターから分岐させる方法、およびすべての変更が最終的にマスターにマージされ、タグ付きバージョンで開発される方法を示します。

GitHub Flow は継続的デリバリー用に設計された軽量ワークフローですが、 Git フロー は、リリース駆動型環境でよく使用される、より構造化された分岐モデルです。 Git フローは GitHub Flow よりも長くなっていますが、mainを既定のブランチとして使用するのではなく、masterという用語が引き続き使用されている可能性があります。

Git フローブランチの種類

Git フローでは、有効期間の長いブランチと一時的なブランチがいくつか使用されます。

  • master: 常に運用対応コードを反映します。
  • 開発: 次のリリースの最新の開発作業が含まれています。
  • feature/*: 新しい機能を作成するために使用されます。が develop から分岐し、完了するとマージされます。
  • release/*: developから新しい運用リリースを準備します。最終的なテストと軽微なバグ修正が可能です。
  • 修正プログラム/*: 運用環境の問題に迅速に修正プログラムを適用するために使用されます。 masterから分岐します。

Git フロー プロセスのしくみ

  1. 開発者は、developから機能ブランチを作成して、新しい機能を構築します。
  2. リリースの時間になると、developからリリース ブランチが作成されます。 これにより、リリース準備作業が分離されるため、開発を中断せずに続行できます。
  3. バグ修正はリリース ブランチに追加できますが、主要な機能は今後のリリースを待つ必要があります。
  4. 準備ができたら、リリース ブランチは master にマージされ、バージョン番号でタグ付けされます。 GitHub では、これらのタグを使用してリリース ノートを生成できます。
  5. 同期を維持するには、同じリリース ブランチを develop にマージし直す必要があります。
  6. 重大な運用バグが発生した場合は、masterから修正プログラム ブランチが作成されます。 修正すると、 master と developの両方にマージされます。

Git フローを使用するタイミング

  • スケジュールされたリリースまたはバージョン管理されたリリースのプロジェクトに最適
  • 複数の運用バージョン (長期的なサポート ブランチなど) を維持する場合に役立ちます。
  • より低速で構造化された開発サイクル (エンタープライズ環境や規制された環境など) に最適
  • ブランチ管理の追加により、GitHub Flow よりも "重い" と見なされる

注

Git フローでは、ブランチを統合するためのマージ コミットが想定されています。 リベースまたはスカッシュマージを使用すると、ブランチ構造と履歴追跡に干渉する可能性があります。

GitHub を使用する多くのチームにとって、GitHub Flow はよりシンプルで高速です。 しかし、チームが予測可能性を評価し、より多くのリリース計画が必要な場合は、Git フローの方が適している可能性があります。

おめでとうございます! ここまで、GitHub フロー全体について説明し、Git フローがリリース駆動型プロジェクトの構造化された代替手段を提供する方法について説明しました。

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