はじめてのGitHub

開発環境

Ryo Nakagami

2025年06月07日

GitHubとは

  • GitHubとは

  • GitHubの機能紹介

  • 参考文献

  • Appendix: Git操作

GitHubが提供する機能

Gitレポジトリホスティング

  • ソースコードの安全な保管

クラウド上でコードを保存することで、紛失リスクを軽減

  • バージョン管理の完全サポート

Gitを使った変更履歴の記録・追跡及び過去の状態への復元や変更内容の比較が可能

開発コラボレーション機能

  • Pull request(PR)

コードの変更を提案し、他のメンバーと議論・承認を経てマージする機能

  • Issue

バグ報告やタスク、提案事項を管理する機能

  • プロジェクト管理ボード

Kanbanスタイルのボードを使って、IssueやPRを視覚的に整理・進捗管理する機能

  • Wiki

ユーザーが自由に編集できるDocumentプラットフォーム

CI/CDツール (GiHub Actions)

  • 自動テスト実行

プッシュやPRのタイミングでユニットテストや統合テストを自動実行する機能

  • 自動デプロイ

本番やステージング環境へ自動でコードをデプロイでき、リリース作業の効率と安定性を実現

  • コンテナ化対応

Dockerなどのコンテナ技術と連携し、開発から本番まで一貫した環境構築と運用が可能

一つのプラットフォームで開発ライフサイクル全体をサポート

従来:個別ツールが必要

Version管理ツール

Git、SVN、Mercurial等を別途導入

Bug tracker

JIRA、Redmine、Bugzilla等を別途利用

Code review tool

Review Board、Crucible等を別途導入

Document管理ツール

Confluence、SharePoint等を別途利用

CI/CDツール

Jenkins、TeamCity等を別途構築

GitHub:統合機能で提供

Git

分散型バージョン管理システム

Issue

バグ追跡・タスク管理・機能要求

Pull Request

コードレビュー・議論・マージ管理

Wiki

プロジェクトドキュメント管理

GitHub Actions

CI/CD・自動化ワークフロー

GitHubの機能紹介

  • GitHubとは

  • GitHubの機能紹介

  • 参考文献

  • Appendix: Git操作

GitHub Issueとは?

GitHub Issue

レポジトリ単位でタスク管理・バグ報告・アイデア共有などを行うために使用する機能

構成要素 説明
タイトル Issueの要点や目的を一言で示す
本文 詳細な説明、再現手順、スクリーンショットなど
Label 種別(bugfeaturehelp wantedなど)を色分けして分類
Assignee Issueの対応担当者を割り当て
マイルストーン リリースやスプリントなどの単位でグループ化可能
コメント欄 ユーザーや開発者が議論・進捗報告を行う場所
クローズ/オープン 対応が完了したら「Closed」にすることで進捗管理が可能
Relationship IssueやPull Request(PR)同士の依存関係を管理する項目

GitHub Issueを用いたコミュニケーション例

GitHub Issue

Mention機能の活用

@username 形式で,対象のユーザーに通知が飛ばせます

LabelでIssueを分類

議論内容を踏まえ,Labelの追加や削除をします

Commitとの紐付けで進捗を自動追跡

  • Issue番号をcommit messageに付与すると,自動的に紐付けができます
  • 左図ではIssue thread に commit-id 09d4a63が確認できる
git commit -m "Fix connection timeout bug (#123)"

他のIssueやPRからの参照

IssueやPRに #番号 を書くと,それがリンクになり相互参照ができます

This issue is related to #45 and blocked by #38.

PRやcommitでのIssueステータス管理

対応状況(Open/Clossed)をcommit messageで管理することができます

gh pr create --base main --head feature \
  --title "Fix login bug causing crash" \
  --body "Fixes #45"

GitHub Issueを用いたワークフロー例の紹介

GitHub Issue

GitHub Issue活用ワークフロー例

Setp1: バグの発見とIssueの作成

問題の言語化と可視化を通して,チーム全体が何が起きているか共有

Step2: ラベルとメタ情報の整理

ラベル・マイルストンの明示によって,タスクを管理しやすくする

Step3: 担当者の割り当てと作業開始

担当者の明確化(@mention)により,進捗確認しやすくする

Step4: Pull Requestを作成し、Issueと関連付け

何のための変更かを追跡でき,レビューや変更履歴の文脈が明確になる

Step5: PRマージとIssueの自動クローズ

作業の完了と状態管理の自動化によって,手動での管理ミスを防ぐ

GitHub Issue作成Tips

① Issueの重複を回避する

  • Issue作成前にキーワード検索して既存のIssueを確認
  • 既存Issueに追記する形が望ましい場合は,新規作成を避ける

② チームで共通のLabelを定義・運用する

  • カテゴリ・優先度・状態を表すラベルを整理(例:bug, preprocess, P1
  • チームでラベル運用ルールを文書化する

③ Issue Templateを定義する

  • .github/ISSUE_TEMPLATE にテンプレートファイルを作成
  • バグ報告・機能提案など,用途ごとにテンプレートを分ける

④ マイルストンを明確に設定する

  • Issueごとにマイルストンを紐づける
  • マイルストンごとの進捗率把握に役に立つ
    • 例: version 3.0 リリースに必要なタスクの95%が現在達成済み

Kanbanを用いたGitHub Issueの管理

GitHub Issue

GitHub Project Board

  • GitHub では Projects(プロジェクトボード) 機能を使って,Kanbanスタイルで最新情報のIssue/PRを管理できます
  • フィルタリング,並び替え,グループ化することでレイアウトを自由にカスタマイズできます

Pull Requestとは?

あるブランチで行った変更について、別のブランチへのマージを依頼するGitHub上の仕組み1 Pull Request

GitHub Pull Requestワークフロー

Step1: ブランチ作成と作業開始

トピックブランチ2を切り、独立して作業を進めることで本線に影響を与えず開発可能に

Step2: コミットとプッシュ

適切な粒度でコミットを行い、GitHubにプッシュして作業状況を共有する

Step3: Pull Request(PR)を作成

レビュー依頼・変更内容の記録・Issueとの関連付けなどを行う

Step4: レビューとフィードバック対応

コメント機能を活用し、コード品質と理解度を高めながら開発を進行

Step5: Pull Requestをマージ

PRを承認・マージし、関連Issueも自動クローズ

GitHub PR活用Tips

① PRとIssueを関連付ける

  • PR本文に Fixes #123 を記述して、マージ時にIssueを自動Close
  • 複数Issueに関連する場合は箇条書きで整理

② Draft PRを活用して作業途中でも共有

  • 作業中でも早期に可視化してコメントをもらえる
  • [WIP]など作業中であることを明確にする

③ PRテンプレートを用意する

  • .github/PULL_REQUEST_TEMPLATE.md にてPRテンプレート設定可能

④ レビュー後の変更は同一ブランチにPush

  • 同じPR内で再レビューが可能になる
  • 会話の文脈を維持したままフィードバック対応ができる

参考文献

  • GitHubとは

  • GitHubの機能紹介

  • 参考文献

  • Appendix: Git操作

サル先生のGit入門

Gitの初心者から中級者までを対象に、バージョン管理の基礎から実践的な操作方法までを解説

saru-git

サイトメタデータ

サイト名 サル先生のGit入門
URL https://backlog.com/ja/git-tutorial/
提供元 株式会社ヌーラボ(プロジェクト管理ツール「Backlog」の開発元)
書籍版 『サルでもわかるGit入門』(インプレス刊)

コンテンツ構成

セクション 内容
入門編 Gitの基本操作(コミット、ブランチ作成など)を図解で解説
発展編 マージやリベース、コンフリクト解消など中級者向けの操作
プルリクエスト編 チーム開発でのプルリクエストの使い方とレビューの流れ
逆引きGit やりたいことからコマンドを探せる便利な逆引きリファレンス

OhGoshGit

初心者~中級者向けに「Git操作でやらかしがちなミスとその直し方」を解説したサイト

OGG

サイトメタデータ

サイト名 OhGoshGit!?!
URL https://ohgoshgit.github.io/
提供元 OhGoshGit
ライセンス MIT License
言語対応 日本語対応セクションあり

コンテンツ構成

  • Git関連のトラブルシューティングや設定ミス対処法を解説
  • Headerから日本語選択可能
  • 具体的なトピック例
    • リモートブランチへのpush/pullができない場合
    • 最新のコミットと作業中の変更との差分を確認方法
    • GitHubリポジトリの名前を変更する方法
    • GitHubリポジトリへのSSH接続を設定する手順

Appendix: Git操作

  • GitHubとは

  • GitHubの機能紹介

  • 参考文献

  • Appendix: Git操作

Gitのバージョン管理の仕組み

Gitコマンドと領域移動関係図

sequenceDiagram

  participant A as working directory<br>(working tree)
  participant B as staging area<br>(index)
  participant C as local repository<br>(local branch)
  participant D as local repository<br>(tracking branch)
  participant E as remote repository

  A->>B: git add/rm
  B->>C: git commit
  C->>E: git push
  C->>A: git switch -c<br>(checkout)
  E->>D: git fetch
  D->>A: git merge
  E->>A: git pull (実質的には git fetch + git merge)

5つのGit管理領域

working directory (working tree)

コードを編集する作業領域

staging area (index)

次のコミットに含める変更を一時的に置く場所

local repository (local branch)

自分のPC上のGitリポジトリ。コミット履歴を保存

local repository (tracking branch)

リモートブランチを追跡しているローカルのブランチ

remote repository

サーバー上の共有リポジトリ(GitHub)

Gitはsnapshot方式で全体の状態を記録

Snapshot形式のデータ管理

差分形式のデータ管理

① 各コミットは「ツリー(tree)」オブジェクトでディレクトリ構造を表現している

② Git はすべてのファイルが各時点で状態をSnapshotで記録し、各ツリーはsnapshotへの参照を保存している

③ 更新がなかったファイルは、前回と同じ blob オブジェクトへの参照リンクを保存している

④ Gitのオブジェクト(コミット、ツリー、ブロブなど)は SHA-1 または SHA-256 のハッシュ値をキーとして保存している

Git × 大容量ファイル ― やってはいけないアンチパターン

大容量ファイルをコミットするのは絶対にやってはいけない

  • Gitは「スナップショット」を丸ごと保管するため、ファイルが変わるたび完全な新コピーをオブジェクト DB に追加してしまう
  • 特に差分アルゴリズムはテキスト向けで、バイナリはほぼ毎回フルサイズ扱いになる

アンチパターン

巨大バイナリをそのままコミット

RAW 動画、可逆圧縮画像、機械学習モデルをcommit

定期的に更新される生成物を履歴に残す

PDF/PowerPoint, minified JS/CSS bundles, compiled binaries

一時ファイルやキャッシュをうっかり追加

.DS_Store, .idea, *.sqlite, *.log

発生する不具合

リポジトリが雪だるま式に肥大化し、clone / fetch が遅くなる

1ファイルでも複数回変更されると何倍にも膨れ上がるリスク有り

生成物が少しでも変わるたびにフルコピーされ履歴が膨張

ファイルの中の一部が変われば、新しい blob オブジェクトが生成される

差分や履歴がノイズまみれになる

開発に不必要な履歴が大量に生成され、修正時系列把握が困難になる