U22. Git / GitHub

ユニット概要

分類: 枝（選択）

依存関係: U1（Rの基礎） → U22

使用データ: なし

学習目標:

  • バージョン管理の必要性と Git の基本概念を理解する
  • リポジトリ、コミット、ブランチ、マージの意味を説明できる
  • Git の基本的なワークフロー（Pull → Edit → Stage → Commit → Push）を実践できる
  • .gitignore を適切に設定できる
  • GitHub Pages を使って静的サイトを公開する手順を理解する
ノートセットアップについて

Git / GitHub の初期設定（アカウント作成、SSH鍵の設定、RStudio連携など）は セットアップガイド を参照してください。このユニットでは、セットアップが完了していることを前提に、Git の概念とワークフローに焦点を当てます。

事前知識: バージョン管理と Git

なぜバージョン管理が必要なのか

研究やレポートを書いていると、ファイル名がこうなったことはないでしょうか：

report.docx
report_v2.docx
report_v2_修正.docx
report_v2_修正_最終.docx
report_v2_修正_最終_本当に最終.docx
report_v2_修正_最終_本当に最終_提出用.docx

このやり方には重大な問題があります：

  • どれが本当の最新版かわからなくなる
  • いつ、何を、なぜ変更したかの記録が残らない
  • 「3日前の状態に戻したい」ができない
  • 複数人で同じファイルを編集すると破綻する

バージョン管理システム（Version Control System, VCS）は、ファイルの変更履歴を自動的に記録し、いつでも過去の状態に戻せるようにする仕組みです。Git は現在最も広く使われているバージョン管理システムで、プログラミングだけでなく論文執筆やデータ分析にも活用されています。

Git の基本概念

リポジトリ（Repository）

リポジトリとは、Git がファイルの変更履歴を管理する場所のことです。プロジェクトのフォルダ全体が1つのリポジトリになります。リポジトリの中には .git という隠しフォルダがあり、すべての履歴情報が格納されています。

リポジトリには2種類あります：

  • ローカルリポジトリ: 自分のPCにあるリポジトリ
  • リモートリポジトリ: GitHub などのサーバー上にあるリポジトリ

コミット（Commit）

コミットとは、ある時点のファイルの状態を記録する操作です。ゲームでいう「セーブポイント」に相当します。

コミットの重要な特徴は、ファイルの全体を毎回コピーするのではなく、前回のコミットからの差分（diff）だけを記録するということです。これにより、リポジトリのサイズが無駄に大きくならず、変更点だけを効率よく確認できます。

各コミットには以下の情報が含まれます：

  • 変更内容: どのファイルのどの部分が変わったか（差分）
  • コミットメッセージ: なぜその変更をしたかの説明
  • 作成者: 誰がコミットしたか
  • タイムスタンプ: いつコミットしたか
  • ハッシュ値: そのコミットを一意に識別するID（例: a1b2c3d）

ステージングエリア（Staging Area）

Git では、ファイルを変更してもすぐにコミットされるわけではありません。ステージングエリア（インデックスとも呼ばれる）という中間領域に「次のコミットに含めるファイル」を明示的に登録する必要があります。

作業ディレクトリ → [git add] → ステージングエリア → [git commit] → リポジトリ

この仕組みがあることで、「10個のファイルを変更したが、そのうち3個だけをコミットしたい」という柔軟な操作が可能になります。

ブランチ（Branch）

ブランチとは、コミット履歴の分岐です。メインの開発ライン（main ブランチ）から枝分かれして、独立した作業を進めることができます。

main:    A --- B --- C --- F --- G
                      \       /
feature:               D --- E

この図では、コミットCの時点で feature ブランチを作成し、DとEの作業を行っています。その間、main ブランチではFの作業が進んでいます。feature の作業が完了したら、Gの時点で main にマージ（統合）します。

ブランチの利点：

  • 実験的な変更を安全に試せる: 失敗してもメインラインに影響しない
  • 複数の機能を並行して開発できる: 各機能を別ブランチで作業
  • コードレビューの仕組みと組み合わせやすい: Pull Request

マージ（Merge）

マージとは、あるブランチの変更を別のブランチに取り込む操作です。通常は機能ブランチの作業が完了したときに main ブランチにマージします。

同じファイルの同じ箇所を2つのブランチで別々に変更していた場合、マージコンフリクト（衝突）が発生します。この場合は手動でどちらの変更を採用するか判断する必要があります。

リモートリポジトリと同期

GitHub はリモートリポジトリのホスティングサービスです。ローカルリポジトリとリモートリポジトリを同期するには、以下の操作を使います：

  • push: ローカルの変更をリモートに送信する
  • pull: リモートの変更をローカルに取り込む
  • clone: リモートリポジトリをローカルにコピーする

.gitignore

.gitignore は、Git の管理対象から除外するファイルやフォルダを指定するファイルです。以下のようなファイルは通常 Git で管理しません：

  • 自動生成されるファイル: .Rhistory, .RData, *.html（Quarto出力）
  • OS固有のファイル: .DS_Store（Mac）, Thumbs.db（Windows）
  • 大きなデータファイル: CSV, Excel など（別の方法で共有する）
  • 機密情報: パスワード、APIキーなどを含むファイル

R プロジェクトの典型的な .gitignore の例：

# R関連
.Rhistory
.RData
.Rproj.user/

# OS関連
.DS_Store
Thumbs.db

# 出力ファイル
*.html
*_files/

# データファイル（大きい場合）
data/*.csv
data/*.xlsx

基本ワークフロー

Git を使った日常の作業は、次のサイクルを繰り返します：

1. Pull    （リモートの最新状態を取得）
     ↓
2. Edit    （ファイルを編集・作成）
     ↓
3. Stage   （変更をステージングエリアに追加: git add）
     ↓
4. Commit  （変更を記録: git commit）
     ↓
5. Push    （リモートに送信: git push）

必ず作業の最初に Pull することが重要です。他の人（または別のPCの自分）がリモートに変更を push している可能性があるためです。Pull せずに作業を始めると、後で push するときにコンフリクトが発生する原因になります。

RStudio の Git タブ

RStudio には Git 操作のための GUI が統合されています。プロジェクトが Git リポジトリになっていれば、右上のペインに Git タブ が表示されます。

  • Diff: 変更内容を確認する（追加された行は緑、削除された行は赤）
  • Commit: ステージングとコミットを行うウィンドウを開く
  • Pull: リモートから最新の変更を取得（青い下矢印）
  • Push: ローカルの変更をリモートに送信（緑の上矢印）

コマンドラインに慣れるまでは、RStudio の Git タブを使うと視覚的に操作できて便利です。

GitHub Pages

GitHub Pages は、GitHub リポジトリから直接 Web サイトを公開できるサービスです。Quarto で作成したサイトや分析レポートを、追加のサーバーなしで公開できます。

設定手順の概要：

  1. リポジトリの Settings を開く
  2. Pages セクションで Source を選択（main ブランチの docs/ フォルダなど）
  3. 保存すると https://<ユーザ名>.github.io/<リポジトリ名>/ で公開される

このサイト自体も GitHub Pages で公開されています。

ランクC: 基礎知識を確認しよう

22-C-1

Git における「コミット」とは何ですか？

コミットは「セーブポイント」のようなものです。その時点のファイルの状態をスナップショットとして記録します。正確には、前回のコミットからの差分（diff）を記録しており、いつでもその時点の状態に戻ることができます。

22-C-2

Git でブランチを使う主な目的は何ですか？

ブランチを使うと、main ブランチ（本線）に影響を与えずに新機能の開発や実験的な変更を行えます。作業が完了したらマージして本線に統合します。失敗した場合はブランチを削除するだけで済みます。

22-C-3

git push と git pull の違いについて、正しい説明はどれですか？

push は自分のPCのコミット履歴を GitHub（リモート）にアップロードする操作、pull は GitHub 上の最新の変更を自分のPCにダウンロードする操作です。共同作業では、作業開始時に必ず pull して最新状態にしてから編集を始めることが重要です。

22-C-4

.gitignore ファイルの役割は何ですか？

.gitignore に記載されたファイルやフォルダは、Git の追跡対象から除外されます。.Rhistory、.DS_Store、大きなデータファイル、機密情報を含むファイルなどを指定するのが一般的です。リポジトリのルートに置きます。

22-C-5

2つのブランチで同じファイルの同じ箇所を異なる内容に変更した場合、マージ時に何が起きますか？

同じファイルの同じ箇所に異なる変更がある場合、Git はどちらを採用すべきか判断できないため、マージコンフリクトが発生します。ファイル内にコンフリクト箇所が次のようにマークされるので、手動でどちらの変更を残すか（または両方を統合するか）を決めます：

<<<<<<< HEAD
自分の変更
=======
相手の変更
>>>>>>> feature-branch

22-C-6

ステージングエリア（Staging Area）の役割は何ですか？

ステージングエリアは、作業ディレクトリとリポジトリの間にある中間領域です。git add でファイルをステージングエリアに追加し、git commit でステージングエリアの内容をリポジトリに記録します。この仕組みにより、変更したファイルのうち一部だけをコミットに含めることができます。

22-C-7

リモートリポジトリについて正しい説明はどれですか？

リモートリポジトリは、GitHub や GitLab などのサーバー上に置かれたリポジトリです。ローカルリポジトリ（自分のPC）と push / pull で同期することで、バックアップ、共同作業、コードの公開が可能になります。clone でリモートリポジトリのコピーをローカルに作成できます。

22-C-8

GitHub Pages について正しい説明はどれですか？

GitHub Pages は、リポジトリ内の HTML ファイルなどを静的 Web サイトとして公開できるサービスです。Quarto で生成した HTML を GitHub Pages で公開すれば、分析レポートやドキュメントを URL 1つで共有できます。無料で利用でき、追加のサーバーは不要です。

ランクB: 実践スキルを磨こう

以下の課題では Git コマンドを使います。RStudio の Terminal タブ、または Mac のターミナルで実行してください。RStudio の Git タブの GUI で同等の操作ができるものもあります。

22-B-1

適当なフォルダに新しい Git リポジトリを初期化してください。初期化後に .git フォルダが作成されていることを確認してください。

git init コマンドでカレントディレクトリを Git リポジトリとして初期化できます。RStudio では File > New Project から Git リポジトリ付きのプロジェクトを作成することもできます。

# 練習用フォルダを作成して移動
mkdir git-practice
cd git-practice

# Git リポジトリを初期化
git init

# .git フォルダが作成されていることを確認
ls -la

RStudio を使う場合は、File > New Project > New Directory > New Project で「Create a git repository」にチェックを入れると、プロジェクト作成と同時にリポジトリが初期化されます。

22-B-2

新しいファイルを作成し、最初のコミットを行ってください。コミットメッセージには変更内容がわかる説明を書いてください。

手順は3ステップです：

  1. ファイルを作成する
  2. git add でステージングエリアに追加する
  3. git commit -m "メッセージ" でコミットする
# ファイルを作成
echo "# Git 練習用リポジトリ" > README.md

# ステージングエリアに追加
git add README.md

# コミット
git commit -m "README.md を作成"

git status を各ステップの間に実行すると、ファイルの状態が変化していく様子が確認できます：

# ファイル作成後
git status
# → Untracked files: README.md

# git add 後
git status
# → Changes to be committed: new file: README.md

# git commit 後
git status
# → nothing to commit, working tree clean

22-B-3

コミット履歴を確認してください。各コミットのハッシュ値、作成者、日時、メッセージが表示されることを確認してください。

git log コマンドでコミット履歴を表示できます。オプションを付けると表示形式を変更できます。

# 詳細なログ表示
git log

# 1行ずつ簡潔に表示
git log --oneline

# 直近3件のみ表示
git log -3

# 変更されたファイル名も表示
git log --stat

git log --oneline は、各コミットを「短縮ハッシュ + メッセージ」の1行で表示するため、履歴の全体像をつかむのに便利です。

22-B-4

新しいブランチを作成し、そのブランチに切り替えてください。ブランチ上でファイルを編集してコミットした後、main ブランチに戻ってください。

git branch ブランチ名 でブランチを作成し、git checkout ブランチ名 で切り替えます。git checkout -b ブランチ名 で作成と切り替えを同時に行えます。

# ブランチの一覧を確認
git branch

# 新しいブランチを作成して切り替え
git checkout -b feature/add-description

# 現在のブランチを確認
git branch
# → * feature/add-description
#     main

# ファイルを編集
echo "このリポジトリは Git の練習用です。" >> README.md

# 変更をコミット
git add README.md
git commit -m "README.md に説明を追加"

# main ブランチに戻る
git checkout main

# README.md を確認（feature ブランチの変更は反映されていない）
cat README.md

main ブランチに戻ると、feature/add-description ブランチでの変更は見えなくなります。各ブランチは独立した作業空間を持っています。

22-B-5

ローカルリポジトリを GitHub のリモートリポジトリに紐づけて、push してください。

事前に GitHub 上で空のリポジトリを作成しておく必要があります。git remote add でリモートを登録し、git push で送信します。

まず GitHub で新しいリポジトリを作成します（README の初期化はしないでください）。

# リモートリポジトリを登録
git remote add origin git@github.com:ユーザ名/リポジトリ名.git

# 登録されたリモートを確認
git remote -v

# main ブランチを push（-u は上流ブランチの設定）
git push -u origin main

-u（--set-upstream）オプションは、ローカルの main ブランチとリモートの main ブランチを紐づけます。一度設定すれば、以降は git push だけで push できます。

RStudio では、Git タブの緑の上矢印ボタンで push できます。

22-B-6

R プロジェクト用の .gitignore ファイルを作成してください。R 関連の一時ファイル、OS固有のファイル、データファイルを適切に除外する内容にしてください。

.gitignore はリポジトリのルートに配置するテキストファイルです。各行にパターンを1つずつ書きます。# でコメント、* でワイルドカード、/ でディレクトリを指定できます。

以下の内容で .gitignore ファイルを作成します：

cat << 'EOF' > .gitignore
# === R 関連 ===
.Rhistory
.RData
.Rproj.user/
*.Rproj

# === Quarto / R Markdown 出力 ===
*_files/
*_cache/
*.html

# === OS 関連 ===
.DS_Store
Thumbs.db

# === データファイル（大きい場合）===
data/*.csv
data/*.xlsx
data/*.rds

# === その他 ===
*.log
EOF

作成した .gitignore もコミットしましょう：

git add .gitignore
git commit -m ".gitignore を追加（R プロジェクト用）"

.gitignore に記載されたファイルは git status にも表示されなくなります。既に追跡中のファイルを後から除外したい場合は git rm --cached ファイル名 で追跡を解除する必要があります。

22-B-7

マージコンフリクトを意図的に発生させ、手動で解決してください。

2つのブランチで同じファイルの同じ行を異なる内容に変更すると、マージ時にコンフリクトが発生します。

# main ブランチで README.md の2行目を編集
echo "main ブランチで追記した内容" >> README.md
git add README.md
git commit -m "main: README に追記"

# 別ブランチを作成して同じ箇所を異なる内容に変更
git checkout -b conflict-demo
# 直前のコミットを取り消して別の内容にする
git reset HEAD~1
echo "conflict-demo ブランチで追記した内容" >> README.md
git add README.md
git commit -m "conflict-demo: README に追記"

# main に戻ってマージを試みる
git checkout main
git merge conflict-demo

コンフリクトが発生すると、ファイル内に以下のようなマークが挿入されます：

<<<<<<< HEAD
main ブランチで追記した内容
=======
conflict-demo ブランチで追記した内容
>>>>>>> conflict-demo

解決手順：

  1. ファイルをテキストエディタで開く
  2. <<<<<<<、=======、>>>>>>> のマークを削除する
  3. 残したい内容だけにする（両方残す、片方だけ残す、新たに書き直すなど）
  4. ファイルを保存する
  5. コミットする
# コンフリクトを解決した後
git add README.md
git commit -m "マージコンフリクトを解決"

22-B-8

GitHub Pages を使って、リポジトリの内容を Web サイトとして公開してください。簡単な index.html を作成し、ブラウザからアクセスできることを確認してください。

GitHub Pages は、リポジトリの特定のブランチ・フォルダから HTML ファイルを配信します。最も簡単な方法は、main ブランチのルートに index.html を置くことです。

# 簡単な HTML ファイルを作成
cat << 'EOF' > index.html
<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>Git 練習サイト</title>
</head>
<body>
  <h1>GitHub Pages テスト</h1>
  <p>このページは GitHub Pages で公開されています。</p>
</body>
</html>
EOF

# コミットして push
git add index.html
git commit -m "GitHub Pages 用の index.html を追加"
git push

GitHub での設定：

  1. リポジトリのページで Settings タブを開く
  2. 左メニューから Pages を選択
  3. Source で Deploy from a branch を選択
  4. Branch で main を選び、フォルダは / (root) のまま Save
  5. 数分待つと https://<ユーザ名>.github.io/<リポジトリ名>/ でアクセスできるようになる

Quarto で作成したサイトを公開する場合は、出力先を docs/ フォルダに設定し、GitHub Pages の Source も docs/ に変更します。_quarto.yml に output-dir: docs を指定してください。

ランクA: AI協働に挑戦しよう

22-A-1

課題: あなたの卒業研究（またはゼミの課題プロジェクト）を Git で管理する計画を立ててください。

AI（ChatGPT、Claude など）に相談しながら、以下を具体的に設計してください：

  1. リポジトリ構成: どのようなフォルダ構造にするか（データ、スクリプト、原稿、図表など）
  2. .gitignore の内容: 何を管理対象外にするか
  3. ブランチ戦略: どのようなブランチを作るか（例: 分析ブランチ、執筆ブランチ）
  4. コミットメッセージの規約: どのようなメッセージの書き方をするか
  5. バックアップと共有: 指導教員とどのように共有するか

提出物:

  • AIとの対話ログ
  • 設計したリポジトリ構成図
  • .gitignore の内容
  • ブランチ戦略の説明

22-A-2

課題: 共同研究プロジェクトのための GitHub リポジトリを設計してください。

AI に相談しながら、以下の要件を満たすリポジトリのセットアップ手順を作成してください：

  • 共同研究者（2〜3人）がそれぞれ別の分析を担当する
  • データは共有するが、大きすぎて Git で管理できない
  • 分析結果のレポートを GitHub Pages で公開したい
  • 誰がいつ何を変更したかを追跡したい

提出物:

  • AIとの対話の記録
  • リポジトリのセットアップ手順書
  • 共同研究者向けの Git 操作ガイド（Pull → Edit → Commit → Push の手順）
  • 大容量データの共有方法の検討結果

まとめ

このユニットでは、Git / GitHub の基本概念とワークフローを学びました：

  • バージョン管理: ファイルの変更履歴を記録し、いつでも過去の状態に戻せる
  • リポジトリ: Git が管理するプロジェクトの単位
  • コミット: 変更の差分を記録するスナップショット
  • ステージング: 次のコミットに含めるファイルを選別する仕組み
  • ブランチ: メインラインから分岐して並行作業し、完了後にマージ
  • push / pull: ローカルとリモート（GitHub）の同期
  • .gitignore: 管理対象外のファイルを指定
  • GitHub Pages: リポジトリから静的 Web サイトを公開

Git は最初は難しく感じるかもしれませんが、研究データやコードの管理に慣れると手放せなくなります。まずは個人プロジェクトで Pull → Edit → Commit → Push のサイクルを繰り返し、体で覚えてください。

進捗: あなたは今 22-C-8 まで完了しました！（と仮定）次は 22-B-1 に進みましょう。