地味な工夫です。このブログのテーマファイルは、GitとGitHubを使って本番サーバーに反映する仕組みにしています。FTPで直接アップロードする方法に比べると初期設定の手間はありますが、変更履歴が残る・ミスがあっても戻せる、というメリットが大きいので、その構築の流れをまとめておきます。
何をGit管理の対象にしたか
方針は単純です。最初に決めたのは「全部をGitに入れない」ということです。WordPress本体・親テーマ(Cocoon)・uploads(メディア)・データベースはGit管理の対象外にして、自分でカスタマイズしている子テーマのフォルダだけをGitリポジトリにしました。WordPress本体や親テーマは配布元が更新するものなので、自分の変更履歴と混ざる必要がありません。uploadsとデータベースは、そもそもコード管理向きの性質のデータではないので、別の方法(必要な時に個別に反映)で扱うことにしています。
そもそもなぜFTPではなくGitにしたのか
理由は明確です。これまでの案件では、修正したファイルをFTPソフトで都度アップロードする運用も普通にやってきました。ただ、それは複数人での作業ではなく、自分一人が慎重に確認しながら進める前提での話です。個人ブログの運営でも、後から見返したときに「いつ・何を・なぜ変更したか」が分からなくなるのは避けたいと思い、最初からバージョン管理を前提にすることにしました。特に、デザインを何度も試行錯誤するタイプの作業(配色やフォントを何度も変更した今回のような進め方)では、コミット履歴が実質的な作業ログにもなってくれるので助かっています。
ローカル→GitHub→本番の流れ
- ローカル(MAMP)で子テーマを編集し、ブラウザで見た目を確認する
git add/git commit/git pushでGitHubのプライベートリポジトリに反映する- 本番サーバーにSSH接続し、子テーマのディレクトリで
git pullする
仕組みは単純です。本番側でリポジトリをそのままgit cloneできる状態にしておけば、以降はgit pull一発で最新のコードを反映できます。
本番サーバーからGitHubに安全に接続する
工夫が必要でした。本番サーバーがGitHubのプライベートリポジトリをpullできるようにするには、認証情報が必要です。ここで自分のGitHubアカウントのパスワードをそのままサーバーに置くのは避けたかったので、「デプロイキー」という仕組みを使いました。
- 本番サーバー上で専用のSSH鍵ペアを新規に生成する
- 公開鍵をGitHubリポジトリの「Deploy keys」に登録する(読み取り専用で設定できる)
- 秘密鍵はサーバー上にのみ置き、外部に出さない
安心材料です。この方法だと、万が一サーバー側の鍵が漏れても、そのリポジトリの読み取り権限しか渡らないので、被害を最小限にできます。自分のGitHubアカウント自体の認証情報を渡すよりずっと安全です。
ローカルからサーバーへのSSH接続も鍵認証にした
認証も揃えました。本番サーバーへのSSH接続も鍵認証で統一しています。レンタルサーバー側で発行された秘密鍵を使い、~/.ssh/configに接続先の設定をエイリアスとして登録しておくと、毎回長いコマンドを打たなくてもssh サーバー名だけで接続できるようになります。小さな時短です。地味ですが、日常的に何度もSSH接続する運用になる場合はかなり効いてくる工夫です。
DBコンテンツはGit管理できないことへの対応
二度手間でした。記事本文や固定ページの内容はデータベースに保存されているので、Gitでは管理できません。プロフィールページの文章を直接編集するような作業では、同じ変更をローカルと本番の両方のデータベースに個別に反映する必要があります。最初は二度手間に感じましたが、コード(見た目・機能)とコンテンツ(文章)を分けて考える習慣がつくと、それぞれ管理方法が違うことにも納得感が出てきました。
運用してみて感じたメリット
実際にこの仕組みで運用を始めてみると、一番のメリットは「変更を戻せる安心感」でした。CSSを調整していて意図しない崩れ方をしたときも、直前のコミットに戻せばすぐに元の状態に復旧できます。まさに命綱。FTPで直接上書きしていた頃は、うっかり誤った状態のまま公開してしまうリスクが常にありましたが、今はコミット履歴を見ればいつ何を変えたかが一目瞭然です。
危険な操作でつまずいた話
肝を冷やしました。構築の過程で一度、本番サーバー上でgit reset --hardを使おうとして、ツール側の安全機構に止められたことがありました。最初は面倒に感じたのですが、落ち着いて考えると、本番のファイルを問答無用で上書きする操作を機械的に止めてくれるのは、むしろありがたい仕組みです。地味だけど頼れる安全弁。結局そのときは、同じ結果をより安全な手順(差分を確認してから個別にファイルを揃える方法)で達成しました。破壊的なコマンドほど「本当にそれしか方法がないか」を一度立ち止まって考える習慣は、個人開発でも意識しておいて損はないと思います。
まとめ
やりすぎではありません。個人ブログの規模でここまでGit/GitHubを使った本番反映の仕組みを作るのはやりすぎに見えるかもしれません。ただ、web制作者としての普段の開発フローをそのままブログ運営にも持ち込めたことで、変更に対する安心感がまったく違います。同じように個人サイトを運営しているエンジニア・web制作者の方には、一度試してみる価値があると思います。
最初に「全部Gitに入れない」と決めたことも、結果的に良い判断だったと感じています。管理対象を絞ったことで、リポジトリの中身がシンプルなまま保てていますし、コミット履歴も自分のカスタマイズだけに集中して追えます。これも設計の成果です。何でもかんでもバージョン管理下に置けばいいわけではなく、対象を絞る判断そのものも設計の一部だと思います。
