Agenda

1-1. プロフィール

2-1. クリエイターとデータの管理

ソフトウェア開発に限らず、原稿や文章などドキュメントを書いたり、デザイナーさんならデザインデータを作成したりすることがあります。

共通しているのは、コンピュータ上で「データを管理する」ということです。

コンピュータを使うクリエイターは、データの管理を行う必要があるのです。

2-2. 人々はデータのバージョン管理をしてきた

コンピュータ上ではデータは「ファイル」単位で管理されます。

ファイルだけでバージョンを管理する方法もあります。

• 原稿_1.docx / 原稿_2.docx とか
• 原稿_最終版.docx / 原稿_最終版_FB対応.docx / 原稿_最終版_FIX.docx とか
• 原稿_20250120.docx / 原稿_20250312.docx / 原稿_20250815.docx とか

別にこれでもいいんです。これで困らなければ。

複数人のクリエイターと共同作業をし始めると、困りごとが生じてきます。

2-3. 同時に作業したいけれど…

AさんとBさんの2人で、原稿の一緒に書くことを考えます。1章をAさん、2章をBさん、3章をAさんが書きたいとき、どうやってデータを管理すればよいでしょうか。

• 原稿.txt を2人がそれぞれのパソコンで複製してから同時に編集すると、Aさんの方では「1章と3章」が書かれ、Bさんの方では「2章」が書かれます。最後に、Aさんの 原稿.txt とBさんの 原稿.txt を合体（マージ）する必要があります。
• もう少し工夫しましょう。原稿_1章.txt と 原稿_2章.txt と 原稿_3章.txt を作り、それぞれを編集すればより管理しやすくなりそうです。
• 書き終えた後で、全てのファイルを確認し合って、合体した完成版 原稿.txt を作ればよさそうです。

なんとかなりそう…？

2-4. 同じ場所を編集したい！

Aさんが1章を書いているとき、Bさんも1章の一部を書きたくなりました。なんなら、Aさんが書いた内容をBさんが修正したいというケースもあります。

• 原稿_1章.txt を共同編集する…？
• AさんもBさんも同時に編集したときに、その両方の内容を活かすには…。2-3 で最初に話した 原稿.txt と同じ問題が生じてしまいます。
• バージョン管理システムで解決しよう！

2-5. バージョン管理システム

「ファイル」ではなく「差分（diff）」に注目してデータを管理します。

• ファイルごとに編集内容を保存してデータを管理するのは無理があった
• どんな編集をしたという「編集内容（差分）」を記録して、合体（マージ）はシステムで行う
• AさんもBさんも、お互いにどの章でも編集できる
• Aさんが編集した内容を、Bさんが修正するということもできる

そうして「バージョン管理システム」が登場しました。

2-6. バージョン管理システムの歴史

「ファイル管理」の時代から「バージョン管理システム」がいろいろ登場していきます。

ここでは時間が足りないので詳しいことは説明できませんが、バージョン管理システムも進化していった結果、使いやすく、データの損失のリスクが低く、バージョン管理システムが置いてあるサーバー（リモートサーバー）と通信ができない状態でもローカルだけで使えるといったメリットを持つ Git が登場したのです。

2-7. 2章まとめ「Git って何？」

• ファイルではなく「差分（diff）」を管理することでデータを管理するシステムのひとつ
• 2008年に登場した、2025年時点で最も使われているバージョン管理システム
• 差分というものは Wiki とか Wikipedia の編集履歴からも確認できる（例：Git - Wikipedia）

3-1. Git でバージョン管理をするには

Git では、あるディレクトリを対象に、その中身を管理します。あるディレクトリを Git 管理するには次の2つの方法があります。

• (1) 作成済みの Git リポジトリを git clone "ここに clone 用の URL" でダウンロードする
• (2) ローカルにある管理したいディレクトリの中で git init を実行する

Git 管理されているディレクトリには .git/ という隠しディレクトリが存在しています（clone や init を実行した頂点のディレクトリだけに存在します。下層ディレクトリには .git/ は存在しません）。

3-2. Git を使ってみる

Git でバージョン管理をするには、次のような流れで「差分」を管理します。

1. 自分の世界を作成する（ブランチの作成、または既存ブランチへの移動）
2. ファイルを編集する（何個でも）
3. 編集内容（差分）を記録する（コミット）
4. 自分の世界の作業内容をリモートサーバーに送信する（プッシュ）

自分の世界を用意する（ブランチ作成）、編集する（差分を作る）、差分を記録する（コミット）、作業内容をリモートサーバー（GitHub）に送信する。

という作業を繰り返すことで、差分を管理しつつ、ひとつのプロダクトを複数人で共同編集できるようになります。AさんとBさんがやりたかったことがスムーズに行えるようになります。

3-3. 自分の世界を作る（作業ブランチ）

バージョン管理システムを使っても、AさんとBさんが同じ世界を同時に編集していたら、お互いの作業内容が衝突してしまいます。

これを防ぐために、Git では「世界（ブランチ）」を複数作成して、異なる世界の中で自由に編集を行います。なお、「世界」という表現は私の資料だけで登場させた概念なので Web 検索しても情報は出てきません。これについて知りたければ「ブランチとは何か」などと調べてみてください。

これによって、例えば同じファイル /sample.txt の1行目に、Aさんが「Aです」と書いて記録して、Bさんが「Bです」と書いて記録したそれぞれの差分を用意したとしても、リモートサーバー（GitHub）上ではそれらを同時に記録・管理できるのです（Aさんの世界では「Aさん」、Bさんの世界では「Bさん」と書かれている、という情報が GitHub 上から見られるようになります）。

3-4. main ブランチという存在

AさんとBさんの世界がばらばらに存在しているだけでは、続きの作業をしたり、「完成版（途中経過でもいいので合体版）」を確認することができずに困ってしまいます。

そこで登場するのが「合体用の世界（ブランチ）」です。好きな名前で「AさんBさん合体世界」といったブランチを作ることもできますが、いわゆる「最終完成版」を表す世界に対応するブランチが main ブランチです。昔は master ブランチという名前でしたが、ポリティカル・コレクトネスの観点から改名されました。

main ブランチが「最終完成版」を意味する世界なので、ここに合体（マージ）された編集内容でプロダクトがリリースされたり、書籍が出版されるという運用が行われます。それ以外の世界（ブランチ）は「実験場」という感じなので、好き勝手に作成した世界（ブランチ）に変な変更内容が入っていても、特に問題はありません。いろいろ実験（試行錯誤）して差分を記録しておいて、そのうちどの差分を main にマージするかを判断する、ということが重要なのです。

3-5. ベースとする世界を確認する（git log）

Git 管理されているディレクトリで、まず git log を実行してみてください。

commit 20d6e85d61b329feca62467c646a5b7a85b802e6 (HEAD -> main, origin/main, origin/HEAD)
Author: debiru <main.coeurl@gmail.com>
Date:   Fri Aug 15 13:13:12 2025 +0900

    add sample pages

これまでのコミットログが確認できます。この続きから編集作業をしたいことを確認できたら、自分の世界（ブランチ）を作成します。

3-6. ブランチを作成する（git branch）

次に git branch -a コマンドを実行してみましょう。

* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/main

いま * が付いている main ブランチにいることが分かります。

作業用の自分の世界を作りたいので、git checkout -b debiru-commit-test のようなコマンドを実行します。もう一度 git branch を実行してみましょう。

* debiru-commit-test
  main

自分の世界である debiru-commit-test ブランチを作成して、そこに移動することができました。

3-7. ファイルを編集する

Git 管理されているディレクトリ内で、まず git status を実行してみてください。

On branch debiru-commit-test
nothing to commit, working tree clean

変更差分が何もないとき、上記のように表示されます。

ファイルを編集してから git status を実行すると、以下のようになります。

On branch debiru-commit-test
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")

3-8. コミットする（git add）

手元でいろいろなファイルを変更したとして、その全て、あるいは一部を記録する操作が「コミット」です。

コミットするには、まず、どのファイル（あるいはファイル内の差分）を「自分の世界」に記録するかを選択する必要があります。

コミット対象を選択するためのコマンドが git add です。git add index.html とすれば、編集した index.html の差分が「ステージングエリア」に追加されます。git status を実行してみましょう。

On branch debiru-commit-test
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        modified:   index.html

3-9. コミットする（git commit）

git status で緑色になっているファイルを「記録」したければ git commit -m "add message into index.html" のようにコマンドを実行します。

これは、コミットメッセージ（どんな変更をしたか、を説明する文章）を付けてコミットを実行するコマンドです。git log を実行すると、これまでのコミット履歴を確認できます。

commit 0f2a573827cbf085c63e61e14d1ba8ab889c24a0 (HEAD -> debiru-commit-test)
Author: debiru <main.coeurl@gmail.com>
Date:   Fri Aug 15 14:16:37 2025 +0900

    add message into index.html

commit 20d6e85d61b329feca62467c646a5b7a85b802e6 (origin/main, origin/HEAD, main)
Author: debiru <main.coeurl@gmail.com>
Date:   Fri Aug 15 13:13:12 2025 +0900

    add sample pages

3-10. GitHub に送信する（git push）

ここまでの作業は、git clone 以外はすべてローカルでの作業でした（つまりインターネットが繋がっていなくても作業できるのです！）。

しかし、あるタイミングで自分の作業内容を他の人にも共有するために、リモートサーバー（つまり GitHub）に送信する必要があります。

なお、これはリモートサーバーに Git リポジトリがあり、そこから clone して作業している場合の話です。git init でローカルに Git リポジトリを作成した場合は push する必要はありません。

git push origin debiru-commit-test を実行すると、「この世界」の作業内容が GitHub に反映されます。

3-11. GitHub から最新情報を取得する（git pull）

Aさんが git push した後で、Bさんがその内容を確認するためには、Bさんは git pull を実行する必要があります。

git pull を実行したい場合は、git status でローカルの差分が存在しないことを確認してください。Aさんの世界を見る、ということは自分の世界から離れるということになります。自分の世界で作業途中のものがある場合は、別の世界に移動できません。

git pull が成功したら、git branch -a で存在するブランチ（Aさんのブランチ名）を確認して、そこに移動してみてください。git checkout A-commit-test を実行するとブランチを移動できます。

4-1. Git リポジトリの関係性（clone と push）

4-2. ローカルリポジトリでの状態遷移

4-3. ブランチとマージ

5-1. Git と GitHub の活用方法

Git や GitHub は、決してシステム開発をしているエンジニアだけのためのものではありません。

非エンジニアであるあなたにとっても、スマートフォンと同じくらい便利な道具です。

Git は基本的に「テキストファイル」の差分を管理するためのもので、画像などのような「バイナリファイル」を管理することには向いていませんが、使い方によっては画像を管理することも可能です。

また、GitHub を使わなくても、git init を使えば、ローカルの手元で気軽に任意のディレクトリを Git リポジトリとして使うことができます。GitHub を応用すれば、デザイナーさんのポートフォリオサイトなども簡単に作ることができるようになります。

そのあたりの応用例は、ここでは話しきれないので、Twitter やブログ記事などで紹介したいと思います。興味があれば @debiru_R までご連絡ください！