設備を改造したとき、何をどう変えたかを台帳に残しますね。

「いつ・誰が・なぜ変えたか」が記録されていないと、トラブル時に原因を遡れません。改造後に不具合が出ても、どの変更が原因か特定できない。現場では当たり前に管理していることです。

GitHubは、その台帳をデジタルで実現したものです。しかも変更の差分が行単位で自動記録され、過去のどの時点にも戻せます。

この記事では、GitとGitHubの仕組みを、設備改造の管理作業に置き換えて整理します。

---

GitとGitHubは別物

「Git」と「GitHub」は名前が似ていますが、役割が違います。最初にここを分けて理解しておくと、後の話がすっきりします。

用語	制御システムの例え	役割
Git	履歴を記録するルール・手順	変更を追跡する仕組みそのもの
GitHub	台帳を保管するクラウドキャビネット	Gitの記録をオンラインで保管・共有する場所

Gitは自分のPC（ローカル）の上で動く仕組みです。GitHubはその記録をインターネット上に上げて保管するサービスです。

「記録のルールと、保管する場所は別」——この整理だけ頭に入れておいてください。

---

1. 「commit」とは何か——台帳への記録確定

設備を改造した後、台帳の「変更内容」欄に記入しますね。「〇〇回路を追加」「インターロック条件を変更」といった記述です。

Gitのcommitはこれに相当します。

git commitというコマンドを実行すると、その時点のファイルの状態がスナップショットとして保存されます。このとき「コミットメッセージ」という一行コメントを残します。

git commit -m "電線サイズ記事の表を修正"

台帳の記入欄と同じです。何をどう変えたかを一言で残す。

重要なのは、commitしない限り履歴には残らないという点です。 「変えたけど台帳に書かなかった」状態と同じです。どれだけファイルを編集しても、commitという操作をしない限りGitは記録しません。

---

2. 「push」とは何か——台帳を本社サーバーに送る

commitは自分のPC上にだけ記録が残った状態です。まだGitHubには届いていません。

git pushというコマンドを実行することで、ローカルの記録がGitHubに転送されます。

例え： 現場で記入した台帳のコピーを、本社の管理部門に送付する作業です。現場に台帳の原本はありますが、本社サーバーにも同じ記録が上がる。pushするまでは、自分のPC以外には存在しない記録です。

前回の記事で説明したCloudflare Pagesへの自動デプロイは、このpushをトリガーに動き出します。「GitHubに台帳が届いた」という通知を受けて、Cloudflareが自動でサイトを更新する——という連携です。

---

3. 変更履歴を「見る」——差分の確認

ここがアナログ台帳との最大の違いです。

アナログ台帳では「変更した」という事実しか残りません。「どこをどう変えたか」は、変更前の図面と変更後の図面を並べて自分で確認するしかない。

Gitは変更前後の差分を行単位で自動記録します。

- 旧：電線サイズは負荷電流の1.25倍を基準とする
+ 新：電線サイズは負荷電流の1.5倍を基準とする

削除した行が赤、追加した行が緑で表示されます。「この一文を書き換えた」「この段落を丸ごと削除した」が一目でわかります。

例え： GX Works2の比較機能でラダー図の変更前後を並べて確認する感覚です。ただしGitはすべての変更に対して自動でこれをやってくれます。手動で並べる必要がありません。

---

4. 「戻す」——改造前の状態に復元する

PLCエンジニアが一番「やってしまった」と感じる瞬間は、改造後にトラブルが発生したときです。

原因が改造にあるとわかれば、改造前の状態に戻すのが最速の対処です。ただしアナログの設備改造では、「戻す」という作業自体がひと仕事です。

Gitではコマンド一発で過去のcommitの状態に戻せます。

git revert <戻したいcommitのID>

「どの時点に戻るか」はcommitの履歴から選べます。1つ前に戻すこともできますし、3週間前の状態に戻すこともできます。

この「戻せる」という安心感が、エンジニアリングの速度を上げます。 失敗しても戻せるとわかっていれば、「とりあえず試してみる」ができます。アナログ台帳の世界では「慎重に慎重を重ねて変える」しかありませんでしたが、Gitがあれば「試して、ダメなら戻す」というサイクルが回せます。

---

5. なぜブログ運営にGitHubが必要なのか

ここまでの話をブログ運営に接続します。

ブログの記事はテキストファイルです。テキストファイルはGitの差分管理が完璧に機能する対象です。

• 「あの表現に戻したい」→過去のcommitから該当箇所を確認できる
• 「先週の版はどう書いていたか」→履歴を辿ればすぐわかる
• 「記事を大幅に書き直したが元に戻したい」→commitしてあれば一発で戻せる

そしてGitHubはCloudflare Pagesと連携しています。pushした瞬間に自動デプロイが走り、サイトが更新される。GitHubは「バックアップ」と「公開トリガー」を同時に担っています。

---

まとめ：用語対応表

Git用語	設備管理の対応概念	操作の意味
repository（リポジトリ）	設備の台帳一式	プロジェクトのファイルと履歴をまとめた単位
commit	台帳への記録確定	変更内容をスナップショットとして保存
push	台帳を本社サーバーに送付	ローカルの記録をGitHubに転送
差分（diff）	変更前後の比較図	何をどう変えたかを行単位で表示
復元（revert）	改造前状態への復帰	過去のcommitの状態に戻す操作

---

おわりに

このブログの記事はすべてGitHubで管理されています。

誤字を直した履歴も、表を追加した履歴も、全部残っています。「いつ・何を変えたか」が行単位で記録されている状態で運用できているのは、Gitという仕組みがあるからです。

設備改造の台帳管理を長年やってきたPLCエンジニアにとって、Gitの考え方は決して遠いものではありません。むしろ 「それをデジタルで自動化したもの」 として、すんなり受け入れられるはずです。

本シリーズはこの2本で完結です。第1回・第2回を合わせて読むと、「Markdownを書いてからサイトが公開されるまで」の全工程が一本の線でつながります。