GitHub FlowにはIssueとプルリクエストを統合することで、問題の追跡とコード変更のレビューを一元化することができます。以下にその主要なステップを示します。
1. Issueを作成する
新しい機能の要求やバグの報告、タスクの定義など、何か新しい作業が必要になったとき、最初に行うことはIssueを作成することです。Issueは作業の内容を明確に説明し、それが何を達成することを目指しているかを定義します。
Issueを作成する際には以下の点に注意します
タイトル: Issueのタイトルはその本質を的確に表現するべきです。例えば、「ユーザープロフィール画面での画像のアップロードエラー」、「新規登録フォームのUI改善」などがあります。
説明: Issueの説明は可能な限り具体的にし、必要なすべての詳細を含めるべきです。問題が何であるか、どのように再現できるか、何が期待される結果であり何が実際の結果であるかを明記します。また、スクリーンショットやエラーメッセージなど、問題を理解するのに役立つ追加情報も含めます。
ラベル: ラベルはIssueをカテゴライズするのに役立ちます。ラベルは「バグ」、「機能」、「改善」などであり、Issueの種類や優先度、状態などを表すことができます。
アサイン: あなたがIssueを解決するつもりである、あるいは特定の人に対応を依頼したい場合は、その人をIssueにアサインします。
マイルストーン: Issueは特定のマイルストーンに関連付けることもできます。これは特定のリリースやプロジェクトフェーズに対応する機能やバグ修正を追跡するのに役立ちます。
タイトル: ユーザープロフィール画面での画像のアップロードエラー
説明:
ユーザープロフィール画面で、新しいプロフィール画像をアップロードしようとするとエラーが発生します。
試したブラウザはChromeとFirefoxで、両方とも同じ問題が起こります。
再現手順：
1. ユーザープロフィール画面を開く
2. 「プロフィール画像を変更」ボタンをクリック
3. 新しい画像を選択して「保存」ボタンをクリック
期待する結果：新しいプロフィール画像が正しくアップロードされ、ユーザープロフィール画面に表示される。
実際の結果：「画像のアップロードに失敗しました」エラーメッセージが表示され、画像は変更されません。
ラベル: bug
アサイン: @username
2. 新しいブランチを作成する
作業を開始する前に、新しいブランチをメインブランチ（通常はmain）から作成します。ブランチ名は作業内容（そして可能であればIssue番号）を反映するようにします。
以下のコマンドを使って新しいブランチを作成します。
git checkout -b [branch-name]
ここで、[branch-name]は新しく作成するブランチの名前です。ブランチ名は作業の内容を明確に反映するような名前にすると良いでしょう。これにより、他の開発者がそのブランチで何が行われているかをすぐに理解することができます。
例えば、Issue #123で報告されたバグを修正するためのブランチを作成する場合、ブランチ名をfix-issue-123とすることができます。また、新しいユーザープロフィール機能を開発する場合、add-user-profileといったブランチ名が考えられます。
ブランチを作成した後は、そのブランチ上で作業を行い、適切にコミットを作成していきます。作業が完了したら、変更をリモートリポジトリにpushし、プルリクエストを作成します。
ここで注意すべきは、1つのブランチには1つのタスク（新機能の追加や特定のバグの修正など）だけを含めるという原則です。これにより、変更を分かりやすくし、レビューを容易にします。
3. 変更をコミットする
ブランチ上で作業を行い、それを小さなコミットに分割してコミットします。各コミットメッセージは明確で、その変更が何をするもので、なぜ必要なのかを説明します。
日本語でコミットメッセージを書いても良いが、非日本語話者が参加する可能性がある場合やオープンソースでの開発の場合は英語で書くことが推奨されます。
日本語のコミットメッセージは文字化けを防ぐために適切な文字エンコーディング（一般にUTF-8）を使用することが重要であることを忘れないでください。
コミットメッセージの例としては、「Add user profile feature」、「Fix image upload bug in profile screen」などがあります。
git commit -m "Add user profile feature" # 英語の場合
git commit -m "ユーザープロフィール機能を追加" # 日本語の場合
4. 頻繁にpushする
ローカルリポジトリの変更をリモートリポジトリ（GitHubなどのオンラインのGitリポジトリ）にアップロードします。これにより、他の開発者もその変更を見ることができます。
ローカルリポジトリで新しいブランチを作成し、そこで作業を進めるとき、作業が進行するにつれて変更をリモートリポジトリにpushするのが一般的なプラクティスです。これには以下のような理由があります。
- バックアップ: コードをリモートリポジトリにpushすることで、万が一ローカルマシンが故障したり、データが失われたりした場合でも、作業の進捗を保持できます。
- コラボレーション: リモートリポジトリに変更をpushすることで、他の開発者がそのブランチをチェックアウトして作業に参加したり、コードレビューを行ったりすることが可能になります。これにより、チーム全体でのコードの透明性と共有が向上します。
- 進捗の可視化: 作業が進行するにつれて変更をリモートリポジトリにpushすることで、他のチームメンバーが作業の進捗を追跡し、必要に応じてフィードバックを提供することができます。
以下のコマンドを使用してリモートリポジトリにpushします。
git push origin [branch-name]
ここで、originはリモートリポジトリの名前（通常はデフォルトの名前）であり、[branch-name]はpushするブランチの名前です。
5. Pull Requestを作成する
作業が完了し、コードがレビューと統合の準備ができたら、プルリクエストを作成します。プルリクエストは作業したブランチの変更をメインブランチにマージするためのもので、この段階でIssueとリンクさせることができます。プルリクエストの説明には、変更の目的、その詳細、テストの手順、関連するIssueなどを明記します。
-
プルリクエストの作成:作業が完了し、コードがレビューとマージの準備が整ったら、プルリクエストを作成します。GitHubのウェブインターフェース上で「New pull request」ボタンをクリックすることで作成できます。その後、比較元と比較先のブランチを選択します。比較元ブランチは、あなたが変更を加えたブランチで、比較先ブランチは、その変更を統合したいブランチ（通常は
main）です。 -
Issueとのリンク:プルリクエストの説明欄には、変更の目的、その詳細、テストの手順、関連するIssue番号（もしあれば）などを記入します。Issue番号を記述することで、プルリクエストとIssueをリンクさせることができます。
例えば、"Fixes #123"や"Closes #123"といった形で記述します。これにより、そのプルリクエストがマージされたときに自動的に該当のIssueが閉じられます。
6. レビューとテスト
チームメンバーがプルリクエストをレビューし、テストを行います。問題や提案がある場合は、プルリクエストにコメントします。
7. マージとデプロイ
レビューが完了し、テストが成功したら、プルリクエストをメインブランチにマージします。
マージされた変更を、すぐに本番環境にデプロイするかどうかはチームで話し合って決めましょう。
8. Issueをクローズする
マージとデプロイが成功したら、対応が完了したIssueをクローズします。
GitHubでは、Issueとプルリクエストを関連付けることが可能です。これにより、特定の問題（Issue）に対する解決策（プルリクエスト）を明確に追跡することができます。
プルリクエストがマージされると、そのプルリクエストに関連付けられたIssueを自動的にクローズ（閉じる）ことが可能です。これは、そのIssueが解決されたとみなすことを意味します。この機能を利用するには、プルリクエストの説明文やコメントに特定のキーワード（例：closes, fixes, resolves）とIssue番号（例：#123）を含める必要があります。
例えば、「Closes #123」や「Fixes #123」と記述すると、そのプルリクエストがマージされたときにIssue番号123が自動的にクローズされます。この機能により、Issueとその解決策の間の関連性が明確になり、チーム全体の作業の進行状況をより正確に把握することができます。
このフローは新しい機能やバグ修正ごとに繰り返されます。Issueとプルリクエストを統合することで、作業の目的とその実装が密接にリンクされ、全体的な透明性とコミュニケーションが向上します。