はじめての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 種別（bug、feature、help 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: リリース中心の開発スタイル

main，develop，feature，release，hotfixに分けて管理するワークフロー

開発の流れに応じた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

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

hotfix

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

テスト駆動開発用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

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

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 コマンドの基本動作

  • Syntax:
    • git log [options] -- <file>
  • 誰がいつリポジトリにcommitして，どのような差分が発生したのかを確認できる(=git rebaseやgit 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 オプションを追加で付与することで，各コミットにおける差分も表示することができます

git log options

オプション 説明
--pretty=format:"%cs %h %an %s" %cs: コミット日時（YYYY-MM-DD）
%h: 短縮コミットID
%an: Author名
%s: コミットメッセージ
-p 各コミットにおける差分（パッチ）を表示
--after=<日付> --after="2025-01-01" で2025-01-01以降にフィルタリング（境界含む）
--before=<日付> --before="2025-01-01" で2025-01-01以前にフィルタリング （境界含む）

.gitginoreの設定

gitコマンド

.gitignoreファイル

  • 不必要なcommitを避けることを目的にGitによる追跡対象としないファイルを指定するための設定ファイル
  • .gitignore に記載された対象ファイルは、git add の実行時に、インデックスに追加されないようになる
  • 「これから追加しない」ための設定

注意点

  • すでに一度 git add を経験したファイルは、インデックスに追加され、Git 追跡対象に含まれてしまうので、後から.girignoreを変更しても意図した通りの動きをしないときがある

すでに追加されたファイルの追跡を解除したい場合

git rm --cached <FILENAME>
  • .gitignore に書かれたファイルを「今後追跡しない」状態に変更
  • ファイルはローカルには残る（削除されない）

Windows + PowershellでのGit環境構築

環境構築

1 公式サイトからインストーラーをダウンロード

2 インストールウィザードに従ってセットアップを進める

Git Bash onlyを選択

「Git Bash only」を選択しておくと環境がシンプルになります

3 インストール完了後，PowerShell を開きPATHの確認

git --version
  • バージョン情報（例：git version 2.46.0.windows.1）が表示されれば成功

4 PowerShellでのGitレポジトリ作成テスト

PS> cd ./Desktop
PS> mkdir ./test
PS> git init
PS> cd ..
PS> Remove-Item ./test -Recurse -Force
  • 上記がエラーなく実行できれば、Git の動作確認は完了

PATHが通らない場合の対処法

Step 1: 実行ファイルの場所を探す

  • git.exeの存在場所を確認する
  • 通常は D:\Program Files\Git\bin\git.exe
Test-Path "D:\Program Files\Git\bin\git.exe"

Step 2: 実行可能性のテスト

& "D:\Program Files\Git\bin\git.exe" --version
  • バージョン情報が出力されれば，次のステップ
  • 出力されない場合はGitの再インストール

Step 3: PATHの追加

  • Test-Path $PROFILE で表示されたprofileファイルに以下のラインを追加
D:\Program Files\Git\bin\git.exe
  • 存在しない場合は，以下のコマンドで新規作成
New-Item -ItemType File -Path $PROFILE -Force