Gitのリモートリポジトリにプッシュすると自動的にWebサイトが更新されるリポジトリを作成する

さくらインターネットのレンタルサーバにはGitが既にインストールされていて、リモートリポジトリを作成することができます。 これを利用して、サイトのファイルのバージョン管理と更新をいっぺんにできないか試してみました。

レンタルサーバがgitをサポートしているかどうかを確認する

まずSSHでプロバイダーのレンタルサーバー領域にアクセスし、Gitのバージョンを確認します。 $ ssh <ユーザ名> @<プロバイダーのレンタルサーバのホスト名> →パスワードを入力 % git —version さくらインターネットのレンタルサーバーのgit git version 2.7.0と表示されました。

bareリポジトリとbareでないリポジトリ

ここで気をつけなければならないことがあります。それはbareリポジトリと、bareでないリポジトリには違いがあるということです。
    • bareリポジトリ
リモートリポジトリとして使用され、ローカルリポジトリからpushされることができる。しかしリポジトリのディレクトリにはファイルが展開されず、ローカルリポジトリの状態が反映されない。 bareの場合
    • bareでないリポジトリ
ローカルリポジトリとして使用され、コミットして、リモートリポジトリへpush、リモートリポジトリからpullすることができる。しかしpushされることができないためリモートリポジトリとして使うことはできない。 nonbareの場合 そのため、単独のリポジトリでは、リモートリポジトリとして使えてファイルの状態をディレクトリに展開させることができません。 これではサイトのファイルのバージョン管理と公開をいっぺんに行うことができません。 では、どうすればいいのか

bareリポジトリとbareでないリポジトリを設置する

イメージとしては、bareリポジトリで集中管理し、サイト公開用のbareではないリポジトリが管理用のbareリポジトリの状態をpullすることで、bareリポジトリの状態を反映させ、ファイルを展開するというものです。 動作イメージ 作業用のPCではbareリポジトリをクローンして作業します。コミットをサイトへ反映させるには、管理用のbareリポジトリへpushし、サイト公開用のbareではないリポジトリがbareリポジトリからpullさせることにより、サイトの状態とローカルリポジトリの状態を同期させます。 gitサーバーの作成手順 そのためには、まずサイトにbareではないリポジトリを設置します。つづいて管理用bareリポジトリを作成(clone)し、管理用bareリポジトリをローカルリポジトリへcloneします。

サイト公開用のbareでないリポジトリを設置

さきほどSSHでログインしたレンタルサーバの領域から、管理したいサイトのディレクトリへ移動します。Webサーバの領域や、WordPressなどのCMSのテンプレート領域などです。 bareでないリポジトリ作成 % cd /home/<ユーザ名>/www/<wordpressのディレクトリ名>/wp-content/themes/<テーマ名>/ % git init つづいて、テンプレート領域にあるファイルを全てaddして、コミットします。 % git add * % git commit -m “add files" これでサイトの状態を記録したサイト公開用bareでないリポジトリが作成されました。

サイト管理用のbareリポジトリを設置

つづいて、先ほど作成したサイト公開用bareでないリポジトリを、管理用のbareリポジトリへcloneします。 同じディレクトリへ配置しても良いのですが、分かりづらくなるので、別ディレクトリへ作成します。 % cd /home/<ユーザ名>/www/ % mkdir repositories % cd repositories % git clone --bare /home/<ユーザ名>/www/<wordpressのディレクトリ名>/wp-content/themes/<テーマ名>/ repo.git bareリポジトリへclone git cloneのオプションに「- -bare」を付けると、bareリポジトリが作成されてそこへcloneされます。repo.gitは管理用リポジトリの名前ですので、適当な名前.gitでかまいません。/とrepo.gitの間にスペースを入れるのを忘れないでください。

サイト公開用のリポジトリに、管理用リポジトリを紐付け

git remoteで、管理用bareリポジトリからpullできるようにします。 %cd /home/<ユーザ名>/www/<wordpressのディレクトリ名>/wp-content/themes/<テーマ名>/ % git remote add origin /home/<ユーザ名>/www/repositories/repo.git サイト公開用のリポジトリも、管理用リポジトリもPCから見たら「リモートリポジトリ」だから、リモートリポジトリ同士でリモートリポジトリとして使うのも変な話ですが、これをやらないとpullができなくなります。

ローカルリポジトリを作成(クローン)

作成した管理用bareリポジトリを、ローカルにクローンします。 SourceTreeを起動して、「URLからクローン」を選択します。そこで先ほど作成したbareリポジトリをクローンしてください。 ソースURL:ssh://<ユーザ名>@<サーバーのホスト名>/home/<ユーザ名>/www/repositories/<bareリポジトリの名前> 保存先のパス:ローカルで管理したいフォルダ 名前:ローカルリポジトリの名前 ローカルへclone クローンが終わると、ローカルで作成したリポジトリに、サイト公開用のファイルが複製されていることが分かります。 ローカルへclone結果

動作確認:ローカルの変更をコミットし、bareリポジトリへpushする

試しにファイルをローカルリポジトリへ追加してみましょう。 「hello.txt」ファイルを追加すると、SourceTreeでは変更が加えられていることがわかります。追加したファイルをコミットしてプッシュします。 ローカルへファイルを追加 最初のコミット 最初のプッシュ すると、bareリポジトリはさきほど追加したファイルを記録します。

動作確認:bareリポジトリをサイト公開用のbareでないリポジトリがpullする

bareリポジトリが記録したファイルを、公開用のリポジトリへ反映させます。 公開用のbareでないリポジトリが管理用bareリポジトリに対してpullすることによって可能です。 先ほどのターミナルに戻り、sshでレンタルサーバの領域へ入り、公開用のbareでないリポジトリのあるディレクトリへ移動します。 % cd /home/<ユーザ名>/www/<wordpressのディレクトリ名>/wp-content/themes/<テーマ名>/ % git pull origin master 手動でpull これにより、ローカルリポジトリの変更が、サイトへ更新されました。 その証拠に、「hello.txt」ファイルが追加されています。 pull結果2

自動化:管理用bareリポジトリが変更されたら、公開用のbareでないリポジトリがpullする

管理用bareリポジトリが変更されたら自動的に実行される仕組みがあります。それが「hook(フック)」です。 動作模式図 bareリポジトリの中身を見てみると、hookというディレクトリがあります。その中に「.sample」というファイル群があります。これらを編集してファイル名から「.sample」を取り除き、実行可能なファイルとして認識させると、自動処理が可能となります。 post-updateを複製 その中から、「post-update.sample」を「post-update」に複製し、編集します。編集に使うテキストエディタは、改行コードやエンコーディングを強制的に変更しないもの使ってください。(macではmiなど) #!/bin/sh cd /home/<ユーザ名>/www/<wordpressのディレクトリ名>/wp-content/themes/<テーマ名>/ || exit unset GIT_DIR git pull origin master post-updateを編集 保存して、アップロードします。 アップロードしたら権限を755に変更します。ターミナル上で行っても、FTPクライアントで行っても構いません。 post-update権限変更 これで、更新されたら公開用のbareではないリポジトリにpullしてもらうフックができあがりました。

動作確認:ローカルの変更をサイトへ反映させる

ローカルのファイル「hello.txt」の内容を変更し、保存します。そしてコミットし、プッシュします。 hello.txtを編集 SourceTreeの変更内容を確認し、コミット&プッシュします。 2行目と3行目が 朝ご飯は納豆と味噌汁でした こんばんは世界 に変更されていることを確認します。 プッシュしたら、サイト公開用のディレクトリを確認し、「hello.txt」を開き、書き換わっていることを確認します。 変更結果が反映 うまく書き換わっていたら成功です! これにより、ローカルで編集した内容をコミット&プッシュすることにより、サイトへ自動的に更新されるシステムができあがりました。

補足

文献やほかのWebサイトに掲載されている情報によると、「post-update.sample」を「post-receive」に名前を変更して、フックを編集するという記述がありました。 しかし、文献の記載はgit version 1.9.0に基づいたもので、post-receiveファイルを作成しても、さくらインターネットのレンタルサーバで使うgit version 2.7.0では動作しませんでした。

参考ページ

ベアリポジトリとノンベアリポジトリ:実践編〜GitでWordPressのテーマを管理 - トリコロールな猫 このシステムを作成する方法にとどまらず、bareリポジトリとそうでないリポジトリの違いや、2つのリポジトリを連携させる仕組みまで詳しく説明してくれていますので、非常に参考になりました。