レンタルサーバー(XREA)で運用しているウェブサイトに、Gitを導入し運用・管理したい。
Gitを導入する為には、SSH通信でサーバーに接続して弄る必要があるので前回の記事ではSSH通信について書きました。
■XREAにリモートリポジトリを作成する。
レンタルサーバー(XREA)にGitをインストールするところから始めないといけないと思っていたのだが、今現在のXREAには、古いバージョンだがGitが既に入っているのでわざわざインストールする必要が無いみたいだ。
最新のGitにアップデートしたいと思ってしまうが、ある程度したらVPSに引っ越す予定なので今は時間短縮の為に入っている物で我慢しようと思う。
●リモートリポジトリを作成する方法
まず、Gitを始める為にはリモートリポジトリを用意する必要がある。
ウェブサイトにリモートリポジトリを作成する方法は、他のサーバーにリモートリポジトリを作成する方法と同じなので「Git リモートリポジトリ作成」とかで検索すれば、やり方が出てくると思います。
●サーバー全体をGitのリモートリポジトリにするか、ウェブサイトやプロジェクト単位でGitのリモートリポジトリにするか、
サーバー全体をGitのリモートリポジトリにしてしまえば、全体の運用更新は楽になるがその分クローンした時のファイル数が重くなってしまったり、まぁ色々面倒な事がある。
なので、ウェブサイトやプロジェクトごとに区切ってリモートリポジトリを作った方が良いかな。
●それでは、リモートリポジトリをサーバーに設置しよう。
既存のウェブサイトをGitで管理したいという事で、既にサーバーにファイルが配置されている。
Gitのリモートリポジトリをサーバーに設置する場合は、空のディレクトリに設定するってほとんどのサイトに書いてあるのだが既にファイルが置かれている場合は、どうなるのだろうか？
１度ディレクトリの中身を空にし、リモートリポジトリを設定後にコミットすべきか？
それとも、ディレクトリに中身が入っているままでもリモートリポジトリを設定する事は出来るのか？
空っぽのディレクトリにリモートリポジトリを設定する事は、色々なサイトに載っているので今回は中身が入ったままのディレクトリにリモートリポジトリを設定してみたいと思う。
中身が入っているディレクトリにリモートリポジトリを設定することによって、なんらかのトラブルが発生する可能性があるので、バックアップを取ってから作業する。
Gitの慣例では、リモートリポジトリのディレクトリ名の末尾に.gitと付ける事になっているらしいが既に設置されているウェブサイトのディレクトリは既に名前がついているし色々と他のプログラムと連携していたりするので、今回は.gitと付けずに作業する。
付けても、他のところで設定しなおせば良いだけなのだが、敢えて今回は.gitを付けない。
●サーバーのファイルのバックアップを取ろう。
サーバーのファイルをバックアップ取ろうと思った時に気づいたのだが、WordPressのローカル側の設定とサーバー側の設定が異なっている事に気づいた。
主に、wp-config.phpの中身のデータベース関連の設定項目が違う。
ローカル側を合わせるか…
結局、何のためにGitをウェブサーバーで使いたいかというとWordPressを魔改造した内容を反映したいという理由が大きいのでここで除外する判断は無い。
configファイルだけ除外するという事も出来るが、何かの手違いで上書きしてしまうミスが発生する可能性もあるので、そういうリスクを無くす意味でもローカル側とサーバー側で一致させて置こうと思う。
ファイル除外とかも追々やりながら覚えないとな。
●WordPressの設定をローカル側とサーバー側で合わせる。
恐らくwp-config.phpとデータベースの設定だけを修正すれば良いと思うのだが、念のためMergeツールを使って確認しておく。
Winmergeというマージツールを使用して、フォルダ全体の差分をチェックしてみたのだが、wp-config.phpとテーマ関連とプラグイン関連の不一致が判明した。
テーマ関連は、ローカル側に入れている物とサーバー側に入れている物がバラバラだったからだ。
ローカル側とサーバー側で合わせようとしたが、ちょっと面倒なので両方のテーマを同一のテーマ１つだけを残し、他は全て削除し合わせる事にした。
プラグインは、サーバー側に入っている物をローカル側にも入れる事で解決した。
wp-config.phpの修正箇所
- DB_NAME
- DB_USER
- DB_PASSWORD
- あとKEY関連とSALT関連も違うぞ…
とりあえず、nameとuserとpasswordを設定しなおしたら自動的にサーバー側と同じに成れば良いのだが…
まず、上記を修正する前にデータベースにサーバー側DBと同一のアカウントを作成する。
- ユーザー名 同一の物にする。
- パスワード 同一の物にする。
define( ‘AUTH_KEY’辺りの認証用ユニークキーも全部同じにする。(どちらかをコピペでOK)
これでマージ作業が完了した。
●マージも完了したので、それでは本当にリモートリポジトリを作成する。
git init --bare --share
上記２つのコマンドを実行すれば、サーバー上にリモートディレクトリが設定する事が出来る。
のだが、上記は空のディレクトリに設定する時のコマンドなので、既にファイルが存在している場合は少し違うのかも知れない。
git initについている–bareというオプションと–shareというオプションについて
–bareは中身のないリポジトリであること指定している。
–sharedはリポジトリを複数のユーザによって共有可能なものにする。
とあるので、「–bareは中身のないリポジトリであること指定している。」という所が合わないので少し調べる必要がある。
●既存のウェブサイトをリモートリポジトリにする場合
対象のディレクトリ内でgit initだけ入力すれば良いみたい。
●共有リポジトリにするか？
正直、一人で作業するので共有リポジトリにする必要性は皆無なのだが、
後から共有リポジトリに変更する事も可能だがパーミッション設定を色々弄らないといけないみたいなので–sharedつけて設定しといた方が楽？なのかな？
まぁどのみち、他者も参加するとなったらグループ設定なりなんなりで結局設定はしないといけないのだけど…
一人で作業するのに、複数人で共有可能にするのはセキュリティ的にちょっとどーなのかとも思うけれど
個人のサイトであり、勉強の為に運営してるサイトなので–sharedつけとこうかな。
ということで、
git init --shared
上記を実行すれば、良きき。
OK！これでリモートリポジトリが完成した。
ls -la
ls -laコマンドを実行し、.gitディレクトリが出来ている事を確認する。
git status
git statusコマンドを実行し、リポジトリの状態を確認する。
ワークツツリーに、index.htmlなどがあるが管理対象になっていない。
git add .
git add .コマンドを実行し、カレントディレクトリにある全てのファイルをインデックスに追加する。
git status
git statusをもう一度叩き、ファイルが管理対象になっている事を確認する。
※ファイルをGitの対象外にしたい場合
.gitignoreという設定ファイルに、対象外とするファイルを設定すると対象外になる。
git addしたら、git commitする。
git commit -m "first commit"
first commitの部分は、コメントなので わかればなんでも良い。
もう一度、git statusコマンドを叩き全てのファイルがコミット済みか確認する。
git status
nothing to commit, working directory cleanと表示されれば、OK！
git logを確認する。
git log
これで、リモートリポジトリは完了です！
●リポジトリを削除する、作り直す
Git管理をやめる場合など、リポジトリが不要になったときは、「.git」ディレクトリを削除します。管理ファイルだけが削除されて、現在のワークツリーのファイルはそのまま残ります。（※3）
※3 ワークツリーにないファイルは削除される。ローカルリポジトリで複数のブランチがある場合、必要なブランチをチェックアウトして、ワークツリーのファイルを別途保存してから削除することを勧める。
リポジトリを作成し直したい場合は、「.git」ディレクトリを削除してから、あらためて「git init」を実行します。
●ベアリポジトリを作成する
ベアリポジトリについては、また今度
■ローカルリポジトリを作成する。
ローカルに作業用フォルダを作成し、cdコマンドで移動する。
例：
$ cd /c/xampp/htdocs/vhtdocs/eccentric-lab.local
ディレクトリを作成したら、「git init」コマンドでローカルリポジトリを作成します。
$ git init
$ git add .
$ git commit -m “コメント”
-m
git commit の実行時に、コミットメッセージを入力できます。簡単なメッセージのみであれば、こちらを使って入力すると素早くコミットを作成できます。
ここまで出来たらリモートリポジトリにpushする。
git remote add [name] [url]
$ git remote add origin https://github.com/ユーザーID/push_test.git
$ git push origin master
ユーザーネームとパスワードを聞かれますので、それぞれのユーザーとパスワードを入力しましょう。
って、ここまでは全て嘘です。たぶん、出来ないと思います。
リモートリポジトリに既にファイルが入っている場合
リモートリポジトリに既にファイルが入っている場合は、ローカルリポジトリからいきなりpushは出来ないので、
一度、ローカルリポジトリにリモートリポジトリのファイルをクローンしてから作業する。
$ git clone ssh://ユーザー名@s001.xrea.com/virtual/ユーザー名/public_html/eccentric-lab.cute.bz
上記のコマンドを実行すると、ローカルにeccentric-lab.cute.bzというディレクトリが作成される。
できれば、別の名前にしたいので
- クローンする前に作業ディレクトリ(ローカルリポジトリ)にしたい名前のフォルダを作成しておいて
- 上記のフォルダがある親ディレクトリに移動して
- クローン時に、最後に作業ディレクトリの名前を指定して実行する。
$ git clone ssh://ユーザー名@s001.xrea.com/virtual/ユーザー名/public_html/eccentric-lab.cute.bz eccentric-lab.local
そうすると、「eccentric-lab.cute.bz」という名前ではなく、「eccentric-lab.local」という名前のフォルダにGitのローカルリポジトリが作成されるます。
そしたら、テストでpushしてみる。
test.txtというファイルを新規で作り、中に適当にテキストを書いて保存する。
$ git add test.txt
$ git commit -m “test txt”
普通は、git remote add originでリモートオリジンを登録しないといけないんだけど、
クローンしてきたから、自動的に登録されているので登録しなくて良い。
別のとこにあげるならremote 先を追加するかorigin変更するかした方が良いけど、今回はやらない。
$ git push origin master
git push origin masterをすると、sshのパスワードを要求されるので入力またはコピペする。
そうするとエラーが出て、pushできない。
理由は、ノンベアリポジトリにはpush出来ないからだ。
ベアリポジトリじゃないとpush出来ない。
git config –add receive.denyCurrentBranch ignoreすると、ノンベアリポジトリにもpush出来るようになるのだが…
$ git config --add receive.denyCurrentBranch ignore
ノンベアリポジトリにpush出来るようにしてしまうと、
一人で作業している分には問題ないが、複数人で作業すると問題が発生するらしい。
なので、どうしたら良いかというと作業用のリモートリポジトリはベアリポジトリで作成し
本番サイトは、ノンベアリポジトリで作成して
ベアリポジトリから本番のノンベアリポジトリへpullする形が一番良いという事だろう。
Git でファイルを一覧にするには ls-files を使います。
$ git ls-files
これだと大量に結果が出てしまいますので、以下のように less コマンドで少しずつ表示できるようにして確認するのが良いと思いました。
$ git ls-files | less
Git の管理対象外のファイルのみ表示する方法
$ git ls-files --others --exclude-standard
オプションの名前が長いので、利用頻度が高い場合は次のような感じでエイリアスを作っておくとよいと思います。
$ git config --global alias.untracked 'ls-files --others --exclude-standard'
上記を実行するには、下記の短い文章を実行するだけ
$ git untracked
参考にしたサイト
https://eng-entrance.com/git-remote
https://atmarkit.itmedia.co.jp/ait/articles/2003/12/news010.html
まとめ
サーバー側
本番サイト：ノンベアリポジトリで作成 (/virtual/ユーザー名/public_html/eccentric-lab.cute.bz)
管理用リモートリポジトリ：ベアリポジトリで作成 (/virtual/ユーザー名/public_html/eccentric-lab.git)
作業したファイルは管理用リモートリポジトリへ転送し定期的に、本番サイトへデプロイする。
まぁ、管理用から本番へpullするだけなのだけどデプロイスクリプト作った方が良いのかどうか？？？
クライアント側
サーバーからクローンでファイル取ってくるか、
ローカルにノンベアリポジトリ作成してから、サーバーからファイルをpullしてくるかの二択かな。
本番サイトを直接sftpとかで弄っちゃうと、トラブルの原因になるので運用更新はGitで一元管理する形にするのかな。
という事で、
サーバーに管理用リモートリポジトリを作成する。
$ git init --bare --share
そうすると、ノンベアリポジトリの時と中身が違う事に気づく。
ノンベアの時は、.gitというフォルダしか出来なかったけどベアリポジトリにすると色々なファイルが出来た。
そしたら、ローカル側で管理用リモートリポジトリをremote originして、
前に登録した奴があるなら、git remote rm originでremoteの情報を消す事が出来る。
$ git remote rm origin
ちなみに消さずに上書きで変更する為にはset-urlを使って、下記のような感じでコマンドを実行する。
$ git remote set-url origin git+ssh://ユーザー名@s001.xrea.com/virtual/ユーザー名/public_html/eccentric-lab.git
originに情報を削除したか、新規で何も登録されてない状態なら下記のようなコマンドを実行する。
$ git remote add origin ssh://ユーザー名@s001.xrea.com/virtual/ユーザー名/public_html/eccentric-lab.git
remote originの内容を確認するコマンドは、下記
$ git remote -v
pushする前に、なんとなくpullしとくか、
$ git pull
pullしても、何も起こらない。
じゃぁ、cloneしておくか、
一つ上の階層に移動して、
$ git clone ssh://ユーザー名@s001.xrea.com/virtual/ユーザー名/public_html/eccentric-lab.cute.bz eccentric-lab.local
いや、クローンせずに今の状態でpush出来るか試してみるか、
$ git add test.txt
$ git commit -m "test"
$ git status
$ git push origin master
クローンしなくても、push出来た。
テストは、このくらいにしてローカルにあるhtmlとかをいっぺんにpushしていく。
$ git add .
$ git commit -m "first"
$ git push origin master
ここまで出来たら、本番用のディレクトリに管理用リモートリポジトリからクローンでファイルを移して
$ git clone /virtual/ユーザー名/public_html/eccentric-lab.git eccentric-lab.cute.bz
以後はpullで管理用リモートリポジトリから本番用のノンリポジトリに更新運用する感じかな。
今後の手順
- 作業を始める前に、管理用リモートリポジトリからpullしてくる。(一人で運用更新する場合は、必要ない。)
- ローカル環境で作業する。
- 作業が終わったら、管理用リモートリポジトリにaddしてcommitしてpushする。
- 本番サイトのノンリポジトリで、管理用リモートリポジトリのファイルをpullして完了
一人で作業する場合は、git側では3と4だけやればOK