GitHub Pull RequestsとIssuesの違い(+Actionsとは)

Pull Requests (プルリクエスト)とIssues (イシュー)は、GitHubの中心的な機能です。

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

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

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

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

「コードを変更したので、確認して取り込んでください」という依頼する機能です。

修正したコードをメインのプログラム（mainブランチなど）に合流（マージ）させる前に、他のメンバーに内容をチェックしてもらうために使います。

いつ使うか:

コードの修正や追加が終わったとき

他の人にコードレビュー（内容の確認）をお願いしたいとき

主な機能:

Diff 表示: 変更前と変更後の差分を一行ずつ確認

Review: 特定の行に対して「ここ、もっとこうした方がいいよ」とコメント

Merge: 承認されたコードを本番環境へ統合

Pull Request の基本的な流れ

１．ブランチを作成	mainブランチから新しい作業用ブランチを作り、その中で修正や機能追加を行います。
２．変更をコミット & プッシュ	作業ブランチにコードをコミットして、GitHubにプッシュします。
３．Pull Request(PR)を作成	GitHub上で「このブランチの変更を main に取り込みたい」とリクエストを出します。 → これが「Pull Request」。
４．レビュー	他の開発者やチームメンバーがPRを確認し、コメントをつけたり、修正を依頼したりします。
５．マージ	問題がなければPRを承認し、mainブランチに「マージ」して変更を反映させます。

Pull Request の役割

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

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

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

「課題・相談・タスク」を管理する掲示板のような機能です。

プログラムのバグ報告だけでなく、新機能の提案や「これってどうすればいい？」という議論まで、あらゆるトピックがここに集約されます。

いつ使うか:

バグを見つけたとき（Bug Report）

新しい機能を追加したいとき（Feature Request）

ToDoリストとしてタスクを整理したいとき

主な機能:

Labels(ラベル): 「バグ」「至急」などのタグ付け

Assignees(担当者): 誰が担当するかを割り当て

Milestones(マイルストーン): 締め切りや目標（バージョンなど）の設定

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

GitHub上で、特定の操作（イベント）をきっかけに、自動で処理を実行してくれる機能のことです。

一般的にはCI/CD（継続的インテグレーション／継続的デプロイ）ツールとして使われます。
例えば、「コードをGitHubに保存（Push）した瞬間に、自動でテストを実行し、問題がなければそのままサーバーに公開する」といった一連の流れを自動化できます。

どういう時に使うのか？
手動で行うと面倒で忘れがちな作業を、すべて自動化できます。

自動テスト	コードを保存するたびに、プログラムが壊れていないかチェックする。
自動ビルド	実行ファイル（.exeや.apkなど）を自動で作成する。
自動デプロイ	修正したWebサイトを自動でサーバー（AWSやVercelなど）にアップロードする。
定時実行	毎日決まった時間にデータを集計したり、バックアップを取ったりする。

キーワード