GitHub フローを調べる
GitHub フローは、GitHub が従来の Git ベースのコラボレーション ソフトウェア開発に価値を追加する方法を示しています。 その目的は、プロジェクトのリポジトリに変更を適用するプロセスに関する規範的なガイダンスを提供することで、GitHub でホストされるプロジェクトの更新を効率化することです。 サンプル シナリオの組織では、GitHub Flow を DevOps プラクティスに組み込むことからメリットが得られる可能性があります。特に、Git ベースのリポジトリの使用経験の欠如を考慮してください。 このユニットでは、GitHub フローの最も一般的なユース ケースを表す一連の手順を確認します。
GitHub フローに従う
GitHub フローは、次の手順で構成されます。
リポジトリの作成。 GitHub フローに従うには、GitHub アカウントとリポジトリが必要です。 既定では、新しいリポジトリには、通常はメイン という名前の既定のブランチが含まれます。
ブランチの作成。 別のブランチを作成すると、既定のブランチに影響を与えることなく、変更を開発して保存できます。 さらに、メイン ブランチにマージする前に変更を確認することで、他のユーザーが変更を共同作業できるようになります。 GitHub で直接ブランチを作成するか、リポジトリをローカル コンピューターに複製し、そこにブランチを作成することができます。
ブランチに対する変更。 コミットを呼び出し、(ローカルで作業している場合は) プッシュ アクションを呼び出して、新しく作成されたブランチに変更を適用します。 GitHub Web インターフェイスを使用して、GitHub でホストされているリポジトリ内のファイルを直接編集できます。 すべてのコミットに対して、適用した変更を説明する短いメッセージを提供します。 変更が完了したと考え、他のユーザーにレビューを依頼する準備ができるまで、これらの手順を繰り返します。
pull request の作成。 作成したブランチへの最後のコミットの後に pull request (通常 は PR と略記) を作成して、フィードバックを要求します。 ブランチに含まれる変更の概要を提供し、その改善の意図について説明します。 特定の個人またはチームにレビューを依頼する場合は、 @ メンション表記を使用します。
pull request の確認。 ここでは、他のユーザーがステップインし、pull request を確認し、コメント、質問、提案など、フィードバックを送信します。
レビューコメントへの対応。 レビューが完了したら、これを反映するように変更を調整し、プルリクエストの承認を待ちます。
pull request のマージ。 pull request を承認すると、作成したブランチの内容を既定の (メイン) ブランチとマージできます。 GitHub は既定で、コメントとコミットを pull request に保持します。これにより、ユーザーや他のユーザーは、いつでも再訪できます。 ブランチ保護を実装する場合、その制限はマージ機能に影響を与える可能性があるため、最初にそれらが満たされていることを確認してください。
ブランチの削除。 マージが完了したら、作成したブランチを削除できます。 これにより、リポジトリのサイズを最小限に抑え、古いブランチが誤って使用されるのを防ぐことができます。