Git をコード以外で活用するユースケース

Git は「プログラマーが使うもの」というイメージがありますが、実際にはテキストベースのファイルを扱う人なら誰でも恩恵を受けられます。

バイナリファイル（画像や Excel など）も管理自体は可能ですが、Git の強みである行単位の差分比較やマージはテキストファイルで真価を発揮します。

以下、具体的な「誰が・何に使えるか」を紹介します。

「レポート_最終版.docx」「レポート_最終版_修正2.docx」のようなファイル名管理から卒業できます。

• 卒業論文・修士論文・学術論文 — 指導教員や共著者のフィードバックを反映するたびにコミット。過去の版にいつでも戻せる
• LaTeX / Markdown — テキスト形式なら差分比較も可能。「どこを直したか」が一目瞭然
• 共同研究・グループワーク — ブランチを使って分担執筆し、最後にマージ

GitHub のプライベートリポジトリを使えば、PC の故障でデータが消えるリスクもなくなります。

原稿の修正履歴を正確に残したい場面は多くあります。

• 技術記事・ブログ — Markdown で執筆し、修正のたびにコミット。公開後の修正履歴も追跡可能
• 書籍の原稿 — 章ごとにファイルを分けてブランチで管理。編集者とのやりとりも Pull Request で
• 翻訳 — 原文と訳文を同じリポジトリで管理し、原文の変更箇所を差分で確認

「いつ・誰が・なぜ修正したか」が記録されるので、複数人での編集作業でも混乱が起きにくくなります。

画像ファイルそのものは Git の差分比較が効きませんが、デザイン周辺にはテキストファイルも多くあります。

• デザイントークン（JSON / YAML） — カラー・フォント・スペーシングの定義をバージョン管理
• Figma / Sketch のエクスポート設定 — 設定ファイルの変更履歴を残す
• SVG ファイル — テキストベースなので差分比較が可能

エンジニアとの連携でも「この色いつ変わった？」が git log で即座に追跡できます。

Infrastructure as Code（IaC）の普及により、インフラ管理と Git は切り離せない関係になっています。

• Terraform / AWS CDK / CloudFormation — インフラ定義ファイルの変更履歴を管理
• Ansible / Chef — サーバー構成の自動化スクリプト
• Docker / docker-compose — コンテナ定義
• GitHub Actions / GitLab CI — CI/CD パイプラインの定義

障害発生時に「いつ・誰が・何を変更したか」を即座に追跡でき、原因特定が格段に速くなります。

分析結果の信頼性には「再現性」が不可欠です。

• SQL クエリ — 集計ロジックの変更履歴を管理。「先月と数字が違う」の原因がすぐわかる
• Python / R スクリプト — 分析コードをバージョン管理し、過去の分析を再実行可能に
• 設定ファイル — 実験条件やパラメータを記録

大容量のデータファイルは Git LFS を使うか、ストレージは別管理にしてスクリプトと設定だけを Git で管理するのが一般的です。

社内規程や業務マニュアルの管理にも Git は有効です。

• 社内規程・就業規則 — 改定履歴を正確に記録。「いつから変わったか」が明確
• 業務マニュアル・手順書 — 複数部署の担当者がブランチで改訂し、レビュー後にマージ
• FAQ・ナレッジベース — Markdown で管理すれば検索性も高い

Word ファイルでの管理と違い、「誰が・いつ・どの行を変えたか」が行単位で記録されるため、監査対応にも有利です。

Git はテキストファイルに最適化されているため、バイナリファイルの管理には注意が必要です。

• 差分が見られない — Word / Excel / 画像は git diff で中身を比較できない
• リポジトリが肥大化する — バイナリは差分圧縮が効きにくく、サイズが膨らみやすい
• マージできない — テキストのようなコンフリクト解消ができず、どちらかを選ぶしかない

バイナリファイルを含める場合は Git LFS を導入するか、.gitignore で除外して専用ストレージで管理することを検討してください。