Git と GitHub の基本 ── 原稿を版管理する

はじめに

原稿_最新.tex、原稿_最新_v2.tex、原稿_最新_v2_修正版.tex。ファイル名で版を管理していると、どれが本当の最新か分からなくなり、変更履歴も追えません。

Git は、こうした「いつ・誰が・どこを・なぜ変えたか」を記録しながら文書を編集していくためのツールです。GitHub はそれを共有してレビューする場所です。latexmk や コンテナと Makefile、GitHub Actions による自動化は、いずれも Git 管理された原稿を前提にします。この記事はその土台を整理します。

Git と GitHub は別物

  • Git … 手元のマシンで動く版管理ソフト。ネットにつながっていなくても使えます。
  • GitHub … Git のリポジトリを預けて、複数人で共有・レビューするためのサービス。同種のものに GitLab や Bitbucket があります。

つまり「Git で記録し、GitHub で共有する」という関係です。Git だけでも版管理はできますが、他の人とやり取りするなら GitHub のような場所があると便利、という位置づけです。

最小限の用語

用語意味
リポジトリ (repository)版管理される作業フォルダ一式。履歴もこの中に入っている
コミット (commit)ある時点のスナップショット。1 コミット＝1 つの意味のある変更
ブランチ (branch)作業の枝分かれ。既定は main
リモート (remote)GitHub 上など、手元の外にあるリポジトリの控え。既定名は origin
clone / push / pull取得（複製）／手元の変更を送る／リモートの変更を取り込む
Pull Request (PR)「この変更を取り込んでほしい」という提案。レビューの単位

最初の一歩

インストール後、まず名前とメールを設定します（コミットの記録に使われます）。

git config --global user.name "Hanako Tanaka"
git config --global user.email "hanako@example.com"

すでに GitHub 上にあるリポジトリで作業するなら clone します。

git clone git@github.com:owner/repo.git
cd repo

手元のフォルダを新たに版管理し始めるなら init します。

cd my-doc
git init

.gitignore で生成物を除外する

LaTeX は .aux や .log、.pdf などの生成物を大量に作ります。これらは履歴に入れず、.gitignore に書いて無視させます。

# LaTeX の中間・生成ファイル
*.aux
*.log
*.out
*.toc
*.fls
*.fdb_latexmk
*.synctex.gz
# 生成物の PDF（CI で作るなら追跡しない）
*.pdf

「ソース（.tex や画像の原本）だけを追跡し、そこから作られるものは追跡しない」が原則です。生成のしくみは latexmk の記事 を参照してください。

基本サイクル

日々の作業はこの繰り返しです。

git status                     # 何が変わったか確認
git add 第3章.tex               # 記録したい変更を選ぶ
git commit -m "第3章 図表番号のずれを修正"
git push                       # GitHub に送る

他の人の変更を取り込むときは pull します。作業を始める前に一度 pull しておくと衝突を減らせます。

git pull

git add は「次のコミットに含める変更を選ぶ」操作です。全部含めたいときは git add -A とまとめられますが、.gitignore を整える前にこれをやると生成物まで入ってしまうので注意します。

ブランチと Pull Request

複数人で同じ原稿を触るときや、大きめの修正をするときは、main を直接いじらず作業用ブランチを切ります。

git switch -c fix/chapter3      # ブランチを作って移動
# … 編集して add / commit …
git push -u origin fix/chapter3 # ブランチごと GitHub に上げる

GitHub 上で Pull Request を作ると、変更点が差分表示され、コメントを付けながらレビューできます。校正のやり取り（ここは全角、ここは表記ゆれ、など）はこの画面で完結します。合意できたら PR を merge して main に取り込み、ブランチは削除します。

git switch main
git pull                       # merge 結果を手元に反映

コミットメッセージの書き方

後から履歴をたどる自分（と共著者）のために、1 行で内容が分かるように書きます。

  • 1 行目に要約（何をしたか）。第2章: 定理2.3の証明を差し替え のように対象を頭に置くと一覧で読みやすい
  • 必要なら 1 行空けて、本文に「なぜ」を書く
  • 「修正」「更新」だけの単語コミットは避ける。何を修正したのかを書く

1 コミットには 1 つの意図だけを入れます。「誤字修正」と「章の再構成」を混ぜると、後で片方だけ戻したいときに困ります。

よくあるつまずき

  • push が拒否される：先にリモートが進んでいます。git pull してから push し直します。
  • コンフリクト（衝突）：同じ箇所を別々に変更すると起きます。ファイルに <<<<<<< などの印が入るので、正しい形に直して git add → git commit します。慌てず 1 ファイルずつ。
  • 生成物をコミットしてしまった：.gitignore に足したうえで git rm --cached *.pdf で追跡を外します（ファイル自体は残ります）。
  • 大きなバイナリ：画像の原本は入れてよいですが、巨大なものは Git LFS を検討します。CI で作る PDF は追跡しないのが基本です。

GitHub でできること

  • Issues … やること・課題の管理。「第4章の図を差し替え」などをチケットにしておく
  • Pull Request レビュー … 差分に行単位でコメント。校正の受け渡しに向く
  • Actions … push や PR を契機に自動処理。LaTeX なら自動コンパイル（GitHub Actions の記事）
  • Releases … 版として確定した成果物（PDF など）に番号を付けて配布

関連記事

まとめ

  • Git は手元で版を記録するツール、GitHub はそれを共有・レビューする場所。
  • 日々の作業は status → add → commit → push、始める前に pull。
  • ソースだけを追跡し、生成物は .gitignore で除外する。
  • 共同作業や大きな変更はブランチ＋ Pull Request で。コミットは 1 つの意図ごとに、要約の分かるメッセージで。

LaTeX組版・教材校正のご依頼・ご相談はコレクトコネクトへお問い合わせください。

← コラム一覧へ