はじめての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などのコンテナ技術と連携し、開発から本番まで一貫した環境構築と運用が可能

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

従来:個別ツールが必要

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活用ワークフロー例

Step1: バグの発見と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]など作業中であることを明確にする
  • レビューを踏まえた変更は同一ブランチにPush

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

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

④ PRのサイズは小さく

  • 開発期間やコード量が大きいほど,レビューの負担は増す
  • 大きな変更は機能単位や修正単位で分割すること

Pull Request フィードバックポイント

Pull Request

コードの可読性

  • コーディング規則と整合的か
  • コメントやドキュメントが適切か

設計・アーキテクチャ

  • 無駄なく効率的な計算か
  • 再利用性・拡張性はあるか

動作の正しさ

  • 要件や仕様を満たしているか
  • 境界条件や例外ケースの考慮があるか

テスト

  • 単体テスト・統合テストが十分か
  • カバレッジやケースの妥当性が確保されているか
  • テストは再現可能な形で成功するか

リファクタリング

  • 冗長なコードや重複が整理されているか
  • 関数やクラスの分割・抽象化が適切か
  • 技術的負債の返済につながっているか

プロジェクトルール遵守

  • コーディング規約・スタイルガイドに沿っているか
  • Gitのコミットメッセージ・ブランチ命名規則が守られているか

ブランチ戦略

  • GitHubとは

  • GitHubの機能紹介

  • ブランチ戦略

  • 参考文献

  • Appendix: Git操作

Git Flow: リリース中心の開発スタイル

maindevelopfeaturereleasehotfixに分けて管理するワークフロー

開発の流れに応じたBranch切り替え

%%{ init: {
    'theme': 'default',
    'themeVariables': { 
        'fontFamily': 'Meiryo'
    },
    'gitGraph': { 
        'orientation': 'LR', 
        'nodeSpacing': 150, 
        'mainBranchName': 'main' 
    }
} }%%
gitGraph
   commit id: "" tag: "v1.0.0"

   branch hotfix
   checkout hotfix
   commit id: "BUGFIX"

   checkout main
   branch develop
   checkout develop
   commit id: "開発開始"

   branch feature/login
   checkout feature/login
   commit id: ""

   checkout main
   merge hotfix tag: "v1.0.1"

   checkout develop
   merge hotfix
   commit id: "incorporate hotfix"
   
   checkout develop
   merge feature/login
   commit id: "ログイン機能実装"

   branch release/1.1.x
   checkout release/1.1.x
   commit id: "リリース準備"
   commit id: "bugfix"

   checkout develop
   merge release/1.1.x

   checkout main
   merge release/1.1.x  tag: "v1.1.0"

   checkout develop
   commit id: "FEATURE"

各種ブランチの役割分担

main

  • 安定版を保持するブランチ
  • git push --tags でリモートレポジトリに tagsをpushする

develop / feature

  • develop は次期リリース向け統合ブランチ
  • feature は新機能開発用で、完成後 develop にマージ

release

  • リリース前のバグ修正や軽微な調整作業用ブランチ
  • 完了したら maindevelop にマージしてタグ付け

hotfix

  • 本番の緊急修正用ブランチ(例: hotfix/<issue number>-hogehoge)
  • main から派生し、修正後 maindevelop にマージ

テスト駆動開発用Git Flow

開発の流れに応じたBranch切り替え(テスト駆動)

%%{ init: {
    'theme': 'default',
    'themeVariables': { 
        'fontFamily': 'Meiryo',
    },
    'gitGraph': { 
        'orientation': 'LR', 
        'nodeSpacing': 150, 
        'mainBranchName': 'main' 
    }
} }%%
gitGraph
   commit id: "" tag: "v1.0.0"

   branch hotfix/1
   checkout hotfix/1
   commit id: "BUGFIX"

   checkout main
   branch system
   checkout system
   commit id: "システムテスト開始"

   branch unit/login
   checkout unit/login
   commit id: "ユニットテスト駆動"

   checkout main
   merge hotfix/1 tag: "v1.0.1"

   checkout system
   merge hotfix/1
   commit id: "Hotfix取り込み"
   
   checkout system
   merge unit/login
   commit id: "ログイン機能統合"

   branch release/1.1.x
   checkout release/1.1.x
   commit id: "リリース準備"
   commit id: "軽微な修正"

   checkout system
   merge release/1.1.x

   checkout main
   merge release/1.1.x  tag: "v1.1.0"

   checkout system
   commit id: "次期機能準備"

  • リモートリポジトリにはmain/release/systemブランチのみ存在
  • 他ブランチはPRマージ後に削除される想定

各種ブランチの役割分担

main

  • 安定版を保持するブランチ
  • リリース済みのコードを管理

system / unit

  • system は次期リリース向け統合ブランチでシステムテストを実施
  • unit/* はユニットテスト駆動開発ブランチで、完成後に system にマージ

release

  • リリース前のバグ修正や軽微な調整作業用ブランチ
  • 完了後 mainsystem にマージしタグ付け

hotfix/*

  • 本番の緊急修正用ブランチ

参考文献

  • 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リポジトリの名前を変更する方法

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のオブジェクト(commit, tree, blobなど)は 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 オブジェクトが生成される

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

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

git logコマンドでcommit logを確認する

gitコマンド

git log コマンドの基本動作

git log [options] -- <file>
  • 誰がいつリポジトリにcommitして,どのような差分が発生したのかを確認できる(=git rebasegit difftoolを使いこなすために必要)
  • ファイルを指定した場合,指定ファイルに関わる変更履歴だけを抽出できる

git log の挙動例

$ git log --pretty=format:'%cs,%h,%an,%s'

2025-09-21,ec4df50,Ryo Nak,Merge pull request #13
2025-09-20,a1b2c3d,John Doe,BUGFIX: solve #11
2025-09-19,9f8e7d6,Alice Smith,ENH: simplify OLS class
2025-09-18,7e6d5c4,Bob Johnson,DOCS: adding README
  • --pretty=format を用いることで,commit logを1行に要約して出力することができます
  • FileやDirectoryのPATHを指定すれば,current branchではなく,指定したPATHに絞ったlogを同じ形式で出力できます
  • -p オプションを追加で付与することで,各コミットにおける差分も表示することができます
  • --pretty=format オプションは以下
    • %cs: コミット日時をYYYY-MM-DD 形式で表示 , %h : 短縮コミットID, %an: Author名, %s: コミットメッセージ