GitHub入門

目標・目的

このサイトでは、チーム開発で必要不可欠なGitHubの「Issue」と「Pull Request」の使い方を学びます。

このテキストは 『Git Hubのアカウントが作成済みであること』と『VSCodeがインストール』されていることを前提としています。また初心者向けに作成していますが、一部はGit HubとVScodeを触ったことがある人向けの内容になっています。

Issueとは

Issueの定義

Issue（イシュー）とは、GitHub上でプロジェクトに関する「やること」や「問題点」、「改善のアイデア」などを記録・管理・共有するための機能です。

もっとわかりやすく言えば、チームで使う「やることメモ」や「相談ノート」のようなものです。

具体的な使用例

  • バグ報告：プログラムの不具合を報告する
  • 機能提案：新しい機能のアイデアを共有する
  • 質問：分からないことや矛盾点を質問・指摘する
  • タスク管理：Todoリストとしてやることを管理するときに使用する

Issueの書き方

基本的な構成と書き方のポイント

  • タイトル

    一目で内容が分かる具体的な件名

    注意点：
    • 曖昧な表現は避ける（例：「バグがある」→「ログインボタンをクリックしても反応しない」）
    • 長すぎるタイトルは読みにくい（50文字以内を目安に）
    • 問題の場所・症状を具体的に記載する
  • 概要

    問題や提案の詳細な説明

    注意点：
    • 感情的な表現は避ける（「ひどいバグ」→「動作しないバグ」）
    • 専門用語ばかりだと他の人が理解できない
    • 5W1H（いつ・どこで・何が・なぜ・どのように）を意識する
  • 再現手順

    バグの場合、どうすれば同じ現象が発生するか

    注意点：
    • 手順を省略しすぎると再現できない
    • 「いつものように」など曖昧な表現は使わない
    • 番号付きリストで順序を明確にする
    • 他の人でも同じ手順で再現できるよう詳細に記載
  • 期待する動作

    本来どうあるべきか

    注意点：
    • 「正常に動く」だけでは不十分
    • 個人的な希望と仕様を混同しない
    • 具体的な動作・結果を明記する
    • ユーザーにとってのメリットも説明する
  • 現在の動作

    現在どのような状態か

    注意点：
    • エラーメッセージがある場合は必ず記載する
    • 「動かない」だけでは情報不足
    • スクリーンショットやエラーログを添付する
    • どの部分が期待と異なるかを明確にする
  • 環境情報

    OS、ブラウザ、バージョンなど

    注意点：
    • 環境情報の記載漏れがあると原因究明が困難
    • 「最新版」ではバージョンが不明確
    • OS・ブラウザ・アプリのバージョンを正確に記載
    • 画面サイズ・デバイス情報も必要に応じて追加
最終チェックポイント
  • 他の人が読んで理解できる内容か
  • 同じ問題を再現できる情報が揃っているか
  • 適切なラベルが付いているか
  • 緊急度・重要度が伝わるか

Issue作成例

タイトル：ログインボタンが機能しない

概要

ログインページのログインボタンをクリックしても反応がなく、ログインできない状態です。

再現手順
  1. ログインページ（/login）にアクセス
  2. メールアドレスとパスワードを入力
  3. 「ログイン」ボタンをクリック
  4. →ボタンクリックしても何も起こらない
期待する動作

ログインボタンをクリックすると、入力された認証情報でログイン処理が実行され、成功時にはマイページに遷移する。

環境
  • OS: Windows 11
  • ブラウザ: Chrome 121.0.6167.160
  • 画面サイズ: 1920×1080
バグ 優先度：高

タイトル：ダークモード機能の追加提案

概要

ユーザーからの要望も多く、長時間の作業でも目が疲れにくいダークモードの実装を提案します。

提案内容
  • ヘッダーにダークモード切り替えボタンを追加
  • 全ページで適用できるようにする
  • ユーザー設定に保存機能を追加
期待される効果
  • ユーザーの目の疲労軽減
  • バッテリー消費の削減（有機ELディスプレイの場合）
  • ユーザー体験の向上
機能改善 優先度：中

Issue番号の確認方法

Issueを作成すると、自動的に番号（#1, #2など）が付きます。この番号は後でPRと紐づける時に使うので確認しておいてください。


Issueを閉じる（Close）とは

Issueには「Open（開いている）」と「Closed（閉じている）」の2つの状態があります。Issueとはいわば問題提起のようなものです。解決したら閉じて行くことで、問題を管理しています。

Open（開いている）状態

  • まだ解決していない問題
  • 対応が必要なタスク
  • 実装待ちの機能提案

Closed（閉じている）状態

  • 解決済みの問題
  • 完了したタスク
  • 実装完了した機能
  • 却下された提案

Issueを閉じる方法

  1. 手動で閉じる

    「Close issue」ボタンをクリックして手動で閉じる

  2. PRとの紐付けによる自動クローズ

    PRの説明に「closes #1」「fixes #1」などと書いておくと、そのPRがマージされた時に自動的に閉じられる

Tips 閉じられたIssueも後から再開（Reopen）できます。例えば、バグが再発した場合などに活用できます。

ブランチとは

ブランチの定義

ブランチとは、ソフトウェア開発においてコードの変更を本体（メインのコードベース）から分離して管理する仕組みです。主に、異なる作業（新機能の追加やバグ修正など）を並行して安全に行うために使われます。ブランチを使うことで、他の作業に影響を与えずにコードを変更・実験でき、後で必要に応じて本体に統合（マージ）することが可能になります。

ブランチ作成を「カレー作り」でたとえると…

main（みんなで食べるカレー鍋）
  • みんなで食べる「完成品」
  • 味や安全性が保証されている
  • 勝手に調味料を入れると全員に影響
作業用ブランチ（自分の小鍋）
  • 自分だけの鍋で新しい具材や味付けを試す
  • 失敗してもみんなの鍋には影響しない
  • うまくできたら「みんなの鍋」に提案
プルリクエストは「味見してもらう」イメージ
1. 小鍋で新しい具材を試す
→ 新機能や修正を自分のブランチで実装
2. みんなに「味見」を依頼
→ プルリクエストでレビューを依頼
3. OKなら本鍋に合流！
→ mainブランチにマージ
ポイント
  • いきなり本鍋（main）に具材を入れない
  • まずは自分の鍋（ブランチ）で試す
  • みんなで味見（レビュー）してから合流（マージ）

mainブランチへの直接プッシュ禁止

多くのプロジェクトでは、mainブランチに特別な「保護設定」がされています。これは、本番環境で使用されるコードの品質と安定性を確保するためです。mainブランチの取り扱いには注意して取り組みましょう。

ブランチの命名規則

推奨される命名パターン

  • feature/add-dark-mode - 新機能追加
  • fix/login-button - バグ修正
  • docs/update-readme - ドキュメント更新
  • refactor/clean-css - コードの整理
メリットとデメリット
    メリット
  • 作業の目的が一目で分かる
  • チーム内での共通認識が持ちやすい
    • デメリット
  • 命名が不適切だと作業内容の把握に時間がかかる

Pull Requestとは

Pull Requestの定義

Pull Request（プルリクエスト）とは、自分の作業内容をチームに見せて相談・提案するための仕組みです。ただ単に書き換えるのではなく、「どこを」「どう変えて」「なぜそうしたのか」を一緒に説明することで、みんなが内容を理解してチームで作業を進めるための“提案と確認”のツールとして使われています。

書き方のポイント

書き方のポイント

  • 1. 関連するIssue番号を記載

    例：「Issue #3 を修正しました」

    なぜ重要か：
    • 紐付けがないと、どの課題に対する修正か不明確になる
    • Issue が自動で Close されず、管理が煩雑になる
    • 修正履歴が追跡しやすく、変更の背景が明確になる
  • 2. 変更理由を明確に

    なぜこの変更が必要だったのかを説明

    なぜ重要か：
    • 理由が不明確だと、レビュアーが意図を理解できない
    • 将来的にコードの変更理由が分からなくなる
    • レビューがスムーズになり、承認までの時間が短縮される
  • 3. 影響範囲を記載

    どのファイル・機能に影響があるかを説明

    なぜ重要か：
    • 影響範囲が不明だと、テスト漏れや予期しないバグが発生
    • レビュアーがどこを重点的にチェックすべきか分からない
    • 効率的なレビューができ、品質向上につながる
    • 他の開発者への影響も事前に把握できる
  • 4. テスト結果を記載

    動作確認やテストの実施状況を報告

    なぜ重要か：
    • テスト状況が不明だと、レビュアーが動作確認から始める必要がある
    • テスト漏れがあった場合、本番でバグが発生する
    • レビュアーがコードの品質を信頼しやすくなる
    • マージ後の安心感が向上する
  • 5. スクリーンショットや動画を添付

    UI変更がある場合は、ビフォー・アフターを視覚的に示す

    なぜ重要か：
    • UI変更の内容が伝わらず、期待と異なる結果になる
    • レビュアーが実際に動かして確認する手間が発生
    • 変更内容が直感的に理解できる
    • デザイナーや非エンジニアもレビューに参加しやすい
提出前の最終チェック
  • 関連Issueが正しくリンクされているか？
  • 変更内容・理由・影響範囲が明確に説明されているか？
  • テストが実施され、結果が記載されているか？
  • レビュアーが理解しやすい構成になっているか？
  • 適切なラベル・マイルストーンが設定されているか？

Pull Requestの例

タイトル：ログインボタンの修正 #3

概要

Issue #3 で報告されたログインボタンの問題を修正しました。

変更内容
  • login.js にイベントリスナーを追加
  • ボタンのクリックイベントを正しく処理するように修正
  • エラー処理を追加
影響範囲
  • ログインページのみに影響
  • 他の機能への影響なし
テスト結果
  • ✅ ログインボタンクリックでフォームが送信される
  • ✅ バリデーションが正しく機能
  • ✅ エラー時のフィードバックが表示される
+ loginButton.addEventListener('click', handleLogin);
+ function handleLogin(event) {
+ event.preventDefault();
+ // ログイン処理
+ }
- // TODO: ログイン処理を実装
関連Issue

Closes #3

バグ修正 レビュー待ち

タイトル：ダークモードの実装 #5

概要

Issue #5 の提案に基づき、ダークモード機能を実装しました。

追加した機能
  • ヘッダーに切り替えボタンを追加
  • ダークモード用のCSSクラスとスタイルを追加
  • ローカルストレージを使用した設定の保存機能
変更したファイル
  • index.html - ボタンの追加
  • styles.css - ダークモード用スタイル追加
  • script.js - 切り替え機能の実装
関連Issue

Closes #5


スクリーンショット
ここにダークモードのビフォー/アフター画像
機能追加 作業中

.gitignoreについて

Pull Requestを作成する前に、不要なファイルが含まれていないか確認しましょう。GitHubにプッシュ（PullRequest）を実行すると、全世界の人がその内容を確認できるようになります。そのため機密情報が含まれるファイルや、不要なファイルを公開しないように設定するファイルが.gitignoreです。

.gitignoreとは

Gitで管理しないファイルやフォルダを指定するための設定ファイルです。

代表的な除外対象
  • 依存関係のフォルダ node_modules/ npmパッケージのインストール先
  • 機密情報 .env, config.json APIキー、パスワードなどを含むファイル
  • 開発環境の設定 .vscode/, .idea/ エディタ固有の設定ファイル
  • ビルド生成物 dist/, build/ コンパイル後のファイル
  • OS生成ファイル .DS_Store, Thumbs.db OSが自動生成する設定ファイル
重要な注意点
  • チーム共有が必要なファイル： 開発に必要な設定ファイルは除外しないように注意
  • プロジェクト固有の設定： フレームワークやツールに応じた適切な設定が必要
Tips
  • プロジェクト作成時に.gitignoreを設定することを推奨
  • GitHubのテンプレート集を活用する
  • チーム内で.gitignoreの内容を共有・合意する

Mergeとは

Mergeの定義

Merge（マージ）とは、ブランチで行った変更をメインのコードに取り込む作業のことです。別々に進めていた作業を、本番用のコードに安全にまとめるために使われます。Pull Requestで提案された内容が承認された後、その変更を正式に組み込む最後のステップがMergeです。

コードレビューの重要性

レビュー作業について

他のメンバーからPull Requestで提出されたコードをチェックし、問題点や改善点を指摘する作業です。チーム開発を行う際はMergeする（本番環境に落とし込む）前に、本当にPushしてもいいかの確認を行います。そのタイミングでチームでのやり取りにこの機能が使えます。

コードレビュー

チームメンバーのコードをチェックし、品質を保つための作業です。

レビューの流れ
  1. PRの内容を確認
  2. 変更されたコードを確認
  3. コメントで指摘・提案
  4. 必要に応じて修正を依頼
  5. 修正確認後、承認
レビューのポイント
レビューを依頼する側
  • 変更内容を明確に説明
  • テスト結果を記載
  • 自己レビューを実施してから依頼
レビューする側
  • 積極的にフィードバック
  • 具体的な改善案の提示
  • タイムリーな対応
レビューコメントの例

悪い例：

"このコードは良くない"

良い例：

"変数名をより具体的にすることで、コードの意図が明確になると思います。例: userInput → loginEmailInput"

Mergeするときの注意点

競合（コンフリクト）とは

複数の人が同じファイルの同じ場所を別々に変更した時に発生する問題です。

具体例
// mainブランチの元のコード
const buttonColor = "green";

// AさんとBさんが同時に変更を加えた場合...
<<<<<<< HEAD
const buttonColor = "red";    // Aさんの変更
=======
const buttonColor = "blue";   // Bさんの変更
>>>>>>> feature/change-color
コンフリクト発生時の対応

コンフリクトが発生すると、GitHub上でPull Requestページに「This branch has conflicts that must be resolved」と表示されます。

1. GitHub上での解決手順
  1. 「Resolve conflicts」ボタンをクリック

    Pull Requestページに表示される「Resolve conflicts」ボタンをクリック します。

  2. コンフリクト箇所を確認

    GitHub上でコンフリクトしているファイルが表示されます

    <<<<<<< feature/your-branch
    
const buttonColor = "red";    // あなたの変更
    
=======
    
const buttonColor = "blue";   // mainブランチの変更
    
>>>>>>> main
  3. 適切なコードを選択・編集

    コンフリクトマーカー（<<<, ===, >>>）を削除し、正しいコードを残します

    あなたの変更を採用する場合
    const buttonColor = "red";
    mainブランチの変更を採用する場合
    const buttonColor = "blue";
    両方を組み合わせる場合
    const buttonColor = "purple"; // 妥協案
  4. 「Mark as resolved」をクリック

    すべてのコンフリクトを解決したら、ファイルごとに「Mark as resolved」ボタンをクリックします。

  5. 「Commit merge」で完了

    すべてのファイルが解決されたら、「Commit merge」ボタンをクリックして解決を確定します。

2. GitHub上で解決できない場合の対処法

複雑なコンフリクトの場合は、ローカル環境で解決するようにしましょう。

  1. 最新のmainブランチを取得 
    # mainブランチに移動して最新化 
    
git checkout main 
    
git pull origin main 
    

    
# 作業ブランチに戻る 
    
git checkout fix-issue-1 
    

    
# mainの内容を作業ブランチに取り込む 
    
git merge main
  2. VSCodeでコンフリクトを解決
    • VSCodeが自動的にコンフリクトファイルを検出
    • 「Accept Current Change」「Accept Incoming Change」「Accept Both Changes」から選択
    • 手動で編集することも可能
  3. 解決後にコミット・プッシュ 
    # 解決した変更を反映 
    
git add . 
    
git commit -m "Resolve merge conflicts with main branch" 
    
git push origin fix-issue-1
コンフリクト予防のコツ
  • 作業前にmainブランチから最新の状態でブランチを作成する
  • 長期間の作業では定期的にmainブランチの変更を取り込む
  • チーム内で作業範囲を事前に調整する
  • 小さな単位でPull Requestを作成する

実践編

実際に手を動かしてみましょう！以下の手順で進めていきます。

Step 1: Issueを立てる

まずは練習用リポジトリにIssueを作成してみましょう。

基本的な手順

  1. GitHubで 練習用リポジトリ を開く
  2. 「Issues」タブをクリック
  3. 「New issue」ボタンをクリック
  4. タイトルと内容を入力
  5. ラベルを設定（後述）
  6. 担当者を設定（必要な場合）
  7. 「Submit new issue」をクリック

ラベル機能について

ラベルはIssueの種類や状態を視覚的に表現する機能です。

主な標準ラベル
bug

バグ報告用

enhancement

機能改善・追加用


documentation

ドキュメント関連

help wanted

助けが必要な課題

ラベルの使い方のコツ
  • 複数のラベルを組み合わせることができます
    bug priority: high
  • プロジェクトに合わせて新しいラベルを作成できます
    design in review
担当者（Assignees）の設定
  • 課題の担当者を明確にできます
  • 複数人をアサインすることも可能
  • 担当者には自動で通知が送られます

Step 2: リポジトリをフォークしてローカルに取得

練習用リポジトリをフォークして、自分のPC上に複製します。

フォークとは

他の人のリポジトリのコピーを自分のGitHubアカウントに作成することです。これにより、元のプロジェクトに影響を与えることなく、自由に変更を加えることができます。

クローンとは

クローンとは、GitHubのリポジトリをローカル（自分のPC）にコピーすることです。

クローンのメリット
  • オフラインでも作業できる
  • 好きなエディタでコードを編集できる
  • ローカルでテストを実行できる
  • 変更履歴を完全に保持できる
注意点：
  • プライベートリポジトリの場合は認証情報が必要
  • 大きなリポジトリは時間がかかる場合あり
  • Git LFSを使用しているリポジトリは追加設定が必要
1. フォークを作成
  1. 練習用リポジトリのページを開く
  2. 右上の「Fork」ボタンをクリック
  3. 必要に応じて設定を確認し、「Create fork」をクリック
2. ローカルにクローン
  1. フォークしたリポジトリページを開く
  2. 緑色の「Code」ボタンをクリック
  3. HTTPSのURLをコピー
  4. VSCodeでターミナルを開く（Ctrl + @）
  5. 適切なフォルダに移動
  6. クローンコマンドを実行
# 作業フォルダに移動
cd プロジェクトを置きたいフォルダのパス
# リポジトリをクローン
git clone https://github.com/あなたのユーザー名/リポジトリ名.git
# クローンしたフォルダに移動
cd リポジトリ名
Tips
  • フォーク元のリポジトリを「upstream」として追加しておくと、元のリポジトリの更新を取り込めます
    git remote add upstream https://github.com/元のユーザー名/リポジトリ名.git
  • VSCodeの場合、GUIからも簡単にクローンできます（Ctrl+Shift+P → 「Git: Clone」）

Step 3: ブランチを作成

VSCodeでブランチを作成します。

  1. VSCodeでリポジトリを開く
  2. 左下のブランチ名をクリック
  3. 「Create new branch」を選択
  4. ブランチ名を入力（例：fix-issue-1）
# ターミナルで実行する場合
git checkout -b fix-issue-1

Step 4: 変更を加える

ファイルを編集してコミットします。

  1. ファイルを編集
  2. 変更を保存（Ctrl+S）
  3. ソース管理パネルを開く（Ctrl+Shift+G）
  4. 変更したファイルをステージング（+ボタン）
  5. コミットメッセージを入力
  6. チェックマークをクリックしてコミット
# ターミナルで実行する場合
git add .
git commit -m "fix #1: ログインボタンのバグを修正"

Step 5: Pull Requestを送る

変更をGitHubにpushしてPRを作成します。

  1. VSCodeで「同期の変更」をクリック（または「publish branch」）
  2. GitHubのリポジトリページに移動
  3. 「Compare & pull request」ボタンをクリック
  4. タイトルと説明を入力（Issueとの紐付けを忘れずに）
  5. 「Create pull request」をクリック
# ターミナルで実行する場合
git push origin fix-issue-1

Step 6: Mergeする

PRの承認からマージまでの流れを見ていきましょう。

今回の練習リポジトリは皆さんにはMerge権限が与えらていないのでできません。やってみたい人は、自分でrepositoryを作成して実践してみましょう。

1. レビュー依頼を受けた時の流れ

コードの確認
  • 変更されたファイルを一つずつ確認
  • コードの品質をチェック（バグ、命名規則、セキュリティ）
  • Issue #3 の内容と修正内容が一致しているか確認
フィードバックの提供

必要に応じて修正依頼やコメントを送ります：

コメントの例：
  • "handleLoginの中にエラーハンドリングを追加した方が良いと思います。"
  • "テストケースにエラー時の動作確認も含めてはどうでしょうか？"

2. マージの実行手順

  1. 承認を行う
    • 「Files changed」タブでレビューを開始
    • 「Review changes」をクリック
    • 「Approve」を選択して承認
  2. マージを実行
    • 「Conversation」タブに戻る
    • 緑色の「Merge pull request」ボタンをクリック
    • マージ方法を選択（通常は「Create a merge commit」）
    • 「Confirm merge」でマージを完了
マージ後の処理
  • Issue #3 が自動的にCloseされます（PRで "fixes #3" と書いた場合）
  • 作業ブランチは不要になるので削除可能です
  • 他のメンバーは `git pull` で最新のmainブランチを取得できます

コンフリクト解決の手順

マージ時にコンフリクトが発生した場合は、以下の手順で解決します：

1. 最新のmainブランチを取得
# mainブランチに移動して最新化


git checkout main


git pull origin main 


# 作業ブランチに戻る 

git checkout fix-issue-1 


# mainの内容を作業ブランチに取り込む 

git merge main
2. コンフリクトの解決

VSCodeのマージエディタを使用して解決します：

  • 赤色の部分: 現在のブランチの内容（あなたの変更）
  • 緑色の部分: 取り込もうとしている内容（mainブランチの変更）
  • 「Accept Current」「Accept Incoming」「Accept Both」から適切な方を選択
3. 変更の反映
# 解決した変更を反映 

git add . 

git commit -m "Resolve merge conflicts with main branch" 

git push origin fix-issue-1