GitHub Pull RequestsとIssuesの違い

	目的	進め方	クローズ方法
Pull Request (PR)	変更したコードをメインに取り込んでもらうための提案	作業用ブランチ → Pull Request作成 → レビュー → マージ	変更がマージされると自動で閉じる
Issues	バグ・要望・アイデアなどやることを管理する	Issue作成 → コメントや担当者決定 → 解決でクローズ	対応が完了したら手動またはPull Requestと連携して閉じる

チーム開発では、以下の流れで使うことが多いです。

１．問題や要望を Issue に書く

２．解決のための変更を Pull Request で提案する

コード変更の提案機能です。

自分が編集したブランチの変更を、メインのブランチ（例: main/master）に取り込んでほしいと依頼する仕組みです。

Pull Request の基本的な流れ

１．ブランチを作成

mainブランチから新しい作業用ブランチを作り、その中で修正や機能追加を行います。

２．変更をコミット & プッシュ

作業ブランチにコードをコミットして、GitHubにプッシュします。

３．Pull Request(PR)を作成

GitHub上で「このブランチの変更を main に取り込みたい」とリクエストを出します。
→ これが「Pull Request」。

４．レビュー

他の開発者やチームメンバーがPRを確認し、コメントをつけたり、修正を依頼したりします。

５．マージ

問題がなければPRを承認し、mainブランチに「マージ」して変更を反映させます。

Pull Request の役割

コードレビュー：ほかの人が内容を確認できる。

議論の場：コメントや提案を通して、設計や実装方針を議論できる。

履歴管理：誰がどんな変更を提案し、どう承認されたかが残る。

プロジェクトの課題管理・タスク管理・ディスカッションの場を提供する機能です。

Pull Requestがコード変更の提案だとすると、Issuesはやるべきことや問題点を整理する掲示板のようなものです。

Issuesでできること

バグ報告
例：「ログイン画面でエラーが出る」

新機能の要望
例：「ダークモードを追加してほしい」

作業タスクの管理
例：「ドキュメントを英語に翻訳する」

議論・アイデア共有
例：「データベース設計をどうするか話し合いたい」

Issues の特徴

・タイトルと本文で課題内容を説明できる。

・コメント機能でチームメンバーが議論できる。

・ラベル（Labels）を付けて分類できる。（例：bug, enhancement, question）

・担当者（Assignees）を設定して、誰が対応するか決められる。

・マイルストーン（Milestones）で期日やリリースに紐づけられる。

・Pull Request と連携
「このPRがマージされたらIssueを自動的にクローズする」ことが可能。
（例：PRの本文にCloses #10と書くと、マージ時にIssue #10 が閉じる）

GitHubリポジトリに組み込まれている自動化ツール（CI/CD: 継続的インテグレーション／継続的デリバリー）の仕組みです。

できることの例

テストの自動実行
コードをpush/PRしたときに、自動でユニットテストを実行。

ビルドの自動化
アプリをビルドし、成果物（artifact）を生成。

デプロイの自動化
AWS・Azure・GCPなどのクラウドに自動でデプロイ。

定期処理（スケジュール実行）
毎日午前0時にスクリプトを実行、などの定期ジョブ。

コード品質チェック
Linterや静的解析ツールを自動で回す。