現在、WordPressをローカルで開発し、GitでコードをGitHubにコミットしてから、サーバーにSSHで接続し、「git pull」を実行してコードを更新しています。これは、WordPressサイトにコードを展開するのに適したオプションですか（この場合、明らかにサーバーへのルートレベルのアクセス権があります）。この場合、Git / GitHubを最大限に活用するにはどうすればよいですか？
回答:
これにはgitを使用しますが、本当にうまく機能します。いくつかの提案：
.gitignoreファイルに追加します。.gitignoreファイルに追加して、開発ワードプレスの設定が本番環境の設定を上書きしないようにします。git post-receiveフックを追加して、Webサーバー経由でwordpressを公開するために使用するディレクトリ（例えば/var/www）に更新を自動的にチェックアウトすることを検討してください。これにより、ファイル自体のみをチェックアウトでき、gitメタデータがWebサーバーのドキュメントルートに到達するのを防ぐことができます。また、アクセス許可の変更をpost-receiveフックに追加して、アクセス許可の一貫性を常に保つことができます。以下に例を示します。
#!/bin/sh
unset GIT_INDEX_FILE
# the directory your web server serves wordpress from
export GIT_WORK_TREE=/var/www/example.com/
# the local directory where your remote git repository sites
export GIT_DIR=/home/git/repos/example.com.git/
# below user is for debain - you want the user and group your webserver uses
sudo git checkout -f
sudo chown -R www-data:www-data $GIT_WORK_TREE
sudo chmod -R 755 $GIT_WORK_TREE
sudo chmod 600 $GIT_WORK_TREE/wp-config.php
sudo chmod -R 775 $GIT_WORK_TREE/wp-contentunset GIT_INDEX_FILEタイプミスの後にバックティックが表示されますか？
Capistranoをセットアップすることを強くお勧めします-最初は少し前向きな作業ですが、その後は新しいセットアップに簡単に使用できます。
主な利点は
どのように設定するかを示すために、カピストラーノスクリプトのセットを追加しています。
キャップファイル
require 'railsless-deploy'
load 'config/deploy'`deploy.rb
set :stages, %w(production staging local)
set :default_stage, "staging"
require 'capistrano/ext/multistage'
set :application, "" # your application name - used to set directory name
set :scm, :git
set :repository, "" # use the ssh repo access line you get from the provider eg git@github.com:name/repo.git
set :deploy_to, "/var/www/#{application}" #this is the root site folder on the remote server
set :deploy_via, :remote_cache # get directly from repo
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]
# makes capistrano ask for sudo password or other remote inputs
default_run_options[:pty] = true
namespace :tasks do
task :fix_links do
run "ln -nfs #{shared_path}/uploads #{release_path}/wp-content/uploads"
run "ln -nfs #{shared_path}/wp-config.php #{release_path}/wp-config.php"
run "ln -nfs #{shared_path}/blogs.dir #{release_path}/wp-content/blogs.dir"
run "ln -nfs #{shared_path}/.htaccess #{release_path}/.htaccess"
run "sudo chown -R www-data.www-data #{release_path}/"
end
end
after "deploy", "tasks:fix_links"最後に、サンプル環境ファイル（マルチステージgemを使用する場合、環境の各ステージ（ローカル、ステージング、プロダクションなど）にこれらのいずれかを使用できます）
config / local.rb
server "", :app #hostname
set :branch, 'develop' #choose branch to deploy
set :use_sudo, false #don't use sudo
set :deploy_to, "/var/www/#{application}" #overwrite default path to deploy toこれらのファイルは微調整しないと機能しない可能性があり、基本的なCapistranoの知識が必要になりますが、うまくいけば一部の人々に役立つでしょう。
これは、私がCapistranoとWordPressを使い始めた最初のチュートリアルでした：http : //theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/
git post-receiveフックは行く方法です！
このトピックについて実際にWordCampプレゼンテーションを行いました。繰り返し説明するのではなく、スクリーンショットを紹介し、ここで説明した非常に簡単な展開スクリプトを紹介します。
要するに、GitHubを使用してレポをホストし、webhookを使用してgit refに基づいて変更をデプロイします。これにより、Vincent Driessenのgit分岐モデルを使用できるようになり、無制限のWebhead、ステージングサーバー、テストサーバーなど、すべて自動展開が可能になります。また、（ファイルの名前を変更してシンボリックリンクすることにより）個別の開発/製品バージョンを維持しながら、バージョン管理下でwp-config.phpを維持することもカバーします。
私はこの質問が少し古いことを知っていますが、ここで答えとしては見ていませんので、シングルサイトのgitベースのセットアップと展開のために私が通常行うことを共有したいと思いますデバイス、ロケーション、および複数の開発者（すべてgitに共通しているように動作する独自のローカルリポジトリを持っています）。
私は心から次の設定を提案できます：
また、概要を説明します（頭を包むために2つ目のリソースが必要な場合）。
基本的には（少なくとも3つのリポジトリで）動作します：
作業が完了したら、クローンを作成したリモートのベアリポジトリにプッシュします。ベアリポジトリには、ライブリポジトリと同期するためのフックがあります（上記のコードではprimeと呼ばれます）。
リポジトリのWordpress固有の設定として、私はこれを持っています.gitignore：
# uploads are data, excluded from source tree
wp-content/uploads/残りを含む。プラグインとテーマの構成は、バージョン/構成の管理下にあります。これにより、ライブで使用する前に、変更を簡単に追跡してコードを確認できます。また、自分の変更により、リモートツリーに対してより簡単にマージできます。これは、Githubで利用可能なWordpressコアに対して特に有用です。
これは、Wordpressのほとんどのニーズにうまく機能します。裸のレポは、競合する変更をプッシュすることを防ぎます。また、ライブサイトを更新する前に、最初にリモートコピーに同期します。つまり、通常、ライブサイトの更新は非常に高速です。フックがあるため、必要に応じて後でWordpressの更新フックを呼び出すこともできます。
これをGithubフックでどれだけ改善できるかを実験していなければ、コードはGithubではなくローカルバージョン管理下にあるため、通常は必要ありません。
このようなシステムを初めてセットアップするには、リモートホストで使用可能なすべてのツールがあるかどうかを評価するために、少し時間をかける必要があります。
最初のセットアップ時間は、1時間から2時間以内に可能になるはずです。環境全体とプッシュを最初に公開します。
ホストによっては、.gitディレクトリをWebアクセスから保護することもできます。以下は、.htaccessWordpressをサブディレクトリ内に配置し、オンラインで公開されていない（有用な）リポジトリ内のスペースを残すコードの例です。
Options -Indexes
# fix trailing slash for .git / make it disappear + .gitignore and similar files.
RedirectMatch 404 ^/\.git(.*)$
# mask 403 on .ht* as 404
<Files ~ "^\.ht">
Order Deny,Allow
Allow from all
Satisfy All
Redirect 404 /
</Files>
RewriteEngine On
RewriteBase /
# map everything into public and set environment var
# to tag the request being valid
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]つまり、パブリックディレクトリ内にないものはすべてオンラインではありません。パブリックディレクトリ内には、たとえばワードプレスのコードベースを配置できます.htaccess。
RewriteEngine On
# mask as 404 if directly accessed
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]これにより、publicに直接アクセスできなくなります。この.htaccess -fooの一部は次のとおりです。.htaccessへのリクエストは403ではなく404を返す必要があります。環境変数については、環境で機能するかどうかをテストする必要があります。また、それをバージョン管理下に置くかどうかを決める必要があります。
ホスティングをより細かく制御できる場合は、ここでより多くのことを行うことができます（異なる/より最適化されています）。上記の例は、一般的な共有ホスティング環境を対象としています（GITを提供し、自分で簡単にインストールできると言うユーザーもいます）まあ、私は通常、ホスティング業者にそのようなものを提供するよう依頼します。
マイナス面として、これには他の回答でも概説されている一般的な問題がいくつかあります。私が誇りに思っていないことの1つは、データベースサーバーが開発コピーを指すように、開発ホストにホストファイルの変更を与えることです。したがって、1つのデータベース構成を保持できます。本当にクールなESPではありません。資格情報のため。
ただし、通常はここではあまり気にしませんが、代わりにリモートシステムで毎日バックアップを実行します。それは簡単で安価だとあなたはWordpressのインストールだけでなく、ファイルのアップロード、データベースの両方の復元することができますし、 gitのレポ。また、バックアップコマンドについては、私は完全に大丈夫ではないかもしれませんが、それらは私のために機能します：
mysql: mysqldump --host=%s -u %s --password=%s %s| gzip > %s
git : git gc
git bundle
files: tar --force-local -czf %s %sここで私が提案することは、Wordpressのインストールに関するプロセスをWordpressから排除することです。特定のシステムで実行する必要があるため、通常はアプリケーション内にありません（たとえば、アプリケーションがダウンする可能性がありますが、これらは引き続き動作する必要があります）。
もう1つの利点は、サイトでチームワークが既に有効になっていることです。追加の裸のレポジトリのおかげで、あなたはあまり間違ったことをすることはできず、マスターブランチやライブブランチから離れたリモートブランチを同僚と共有することさえできます。