gitを使用してWPダッシュボードから更新するWP Webサイトプロジェクトをどのように構成する必要がありますか？

数か月間、WPダッシュボードを介してコアとプラグインを更新する機能を犠牲にせず、型破りなディレクトリ構造（wp -WPの親フォルダーの外のコンテンツ）、Webサイト全体の管理と展開が簡単です。私はサブモジュール、サブツリー、ネストされたリポジトリなどについて読みましたが、それをすべて合わせて適切な戦略を選択するのに苦労しています。

括弧でgitリポジトリを処理する方法についての考えとともに、ここに私が今考えているものがあります。

root (main project repo)
|-- wordpress (public git repo added as subtree)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo added as subtree)
|    |    |    |-- other-plugin-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-plugin-without-git-repo (ignored/untracked)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo added as subtree)
|    |    |    |-- other-theme-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-theme-without-git-repo (ignored/untracked)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

これにより、いくつかの問題/質問が残ります。

• 自動更新; 新しい自動更新機能が大好きです。サイトを更新して安全に保つために時間と労力を大幅に節約できる可能性がありますが、gitでコードの変更を追跡するのに苦労するようです。WordPressコアの自動更新を許可しながら、コードの変更を追跡する方法はありますか？

• WordPressコアレポジトリの下にサブツリーがあると、gitを使用して新しいコアアップデートにマージしたり、WordPressコアレポジトリに変更をプッシュしたりできなくなります（コアコントリビューターになりたい場合）。

• パブリックgitリポジトリを持たないプラグインの場合、それらを完全に無視すると、ファイルを手動でサーバーにコピーせずにサイト全体を新しいサーバーにすばやく複製できないという問題が発生します。また、プラグインのコードを変更したい場合、それらの変更は追跡されず、プラグインのアップグレードで簡単に失われる可能性があるため、問題が発生します。

要約すると、これらの問題を回避する優れたgit + WordPressセットアップは何ですか？提案されたプロジェクト構造についてのフィードバックをお待ちしています。あなたが私がこれを改善するのを助けることができるどんな方法でも、大歓迎です！

PS、この議論のためのより良いフォーラムがあれば、そこに私を向けてください。

私の観点からすると、あなたの計画にはGitと「従来の」構造という2つの問題があります。基本的にすべて。:)

1. Git（および一般的なバージョン管理）は、サイトスタック全体にとっては貧弱なツールです。そこに行って、それをしました

2. コンテンツをコアから分離した「型破りな」構造と呼ばれるものは、しばらくの間、深刻なサイトにとって非常に慣習的で堅牢な選択でした。

3. サイトスタック全体とネイティブアップデートを組み合わせるターンキー方式はほとんどありません。異なるレベルのプロジェクト（制御の開発者と制御のエンドユーザー）で異なる目標を達成しようとするため、うまく連携しません。

現在、サイト全体のWordPressスタックの最善策はComposerですが、意見は慎重になるかもしれません。:)

特定の懸念について：

1. 上記のように、厳密に制御されたスタックでは、ネイティブ更新（より自動）がうまく機能しません。

2. WordPressコアはGitで開発されておらず、プルリクエストを受け入れません。すべての貢献は（これまでのところ）Subversionへのパッチファイルを介して行われます。

3. そのようなプラグインをリポジトリにコミットする必要があるでしょう。または、Composerなどの別のアプローチを使用します。

あなたは見てかかることがあります。この問題とこの問題を。

また、各リポジトリのREADMEファイルもご覧ください。

• markjaquith / WordPress-Skeleton
• davidwinter / wordpress-with-git

上記のリポジトリに基づいて、Git / WPセットアップの別の例として、これを作成しました。テーマにシンボリックリンクを使用することを選択しました（これをREADMEでカバーしようとしています）。

私は自動更新と同じボートでちょっとしています...私の計画は、更新が発生したときに手動でWPサブモジュールを更新することでした。代替案は、理論的には（まだ自分でテストしていない）、サブモジュールがマイナーアップデートのためにそれ自体を更新するようにし（これにはWP設定があります）、gitメジャーアップデートが出たときにサブモジュールの強制/リセットを行うことだと思います（おそらく、ここでの答えの1つは何らかの助けになるかもしれません...もちろん、次のメジャーリリースに更新するときに特定のWPタグをターゲットにしたいと思うでしょう。

注意すべきことの1つは、WPが.gitパスを検出すると、自動更新を自動的にオフにすることです。詳細については、以下を参照してください。

• 自動コア更新、更新

自動更新を有効にするには、いくつかの簡単な要件があります。

• インストールが更新にFTPを使用する場合（および資格情報のプロンプト）、自動更新は無効になります
• インストールがSVNまたはGITチェックアウトとして実行されている場合、自動更新は無効になります
• 定数DISALLOW_FILE_MODSまたはAUTOMATIC_UPDATER_DISABLEDが定義されている場合、自動更新は無効になります
• 定数WP_AUTO_UPDATE_COREがfalseとして定義されている場合、自動更新は無効になります
• WordPressインストールもHTTPS接続を介してWordPress.orgにアクセスできる必要があるため、PHPインストールもOpenSSLインストールして動作する必要があります。
• Wp-Cron 何らかの理由でcronがインストールで機能しない場合、自動更新も使用できなくなります。

その他の関連リンク：

• WP 3.7自動更新
• GitHubサブモジュールのテーマ開発？
• GitでWordPressをインストールして管理する

2015年5月の更新

このレポジトリを作成したので、WordPressプロジェクトをすばやく開始できます。私の最新のアプローチは、テーマのみをバージョン管理することです。言い換えると、WPをローカルに（前述のリポジトリのセットアップを使用して）運用環境にインストールし、次に各システムの構成ファイルを変更しgit、テーマを引き出して機能的なサイトを取得します。

このタイプの開発は、「それほど簡単ではなく、満足するには時間がかかるカスタムワークフローが必要」に分類されます。

サブツリー、サブモジュール、ネストされたリポジトリ、お尻の大きな痛みを見つけました。

いくつかの考え（すべてを追跡）。

1. 次を使用してgit / svnで自動更新を有効にします。
   add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

手動コミット+メールによる安全な方法：

ステージングサーバーを使用して、更新通知を自分にメールで送信し、更新をコミットして、自動更新がオフになっているライブサーバーにプッシュできます。

これにより、自分のリポジトリ用のフォルダを自由にコピー/ペーストすることもできます。これは私がよく行う方法です。また、複数のステージングサーバーを簡単に複製/破棄できます。Gitは配布されるため、このメソッドで実際に有効になります。

欠点：フォルダのコピー/貼り付け、管理。

自動方式

ビルドスクリプト（Phing、Ant、Bash、Capistranoなど）と、更新プログラムが適用されたときにgit add + commitを実行してライブサーバーに送信するカスタムコードをセットアップします。また、プラグイン/テーマリポジトリを分離し、スクリプトをコンパイル/移動/それらが何であれ、および/またはミックスでComposerを使用することもできます。

このようなワークフローの自動化も柔軟性に欠ける傾向があり、投資する時間が本当に必要な場合にのみ価値があります。

欠点：柔軟性がなく、作成に時間がかかります。

Gitはバックアップには使用しないでください。一般的に言えば、WPのコミット履歴を複製する必要はありません。

さらに考えてみると、私はネイティブのWP更新を利用して自分の作業を節約したいので、WPがgitを使用して更新するものを追跡することは意味がありません。ここに修正されたアイデアがあります。

root (main project repo)
|-- wordpress (ignored/untracked)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo not connected to parent)
|    |    |    |-- other-plugin (ignored/untracked)
|    |    |    +-- modified-plugin (unignored, added to main project repo)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo not connected to parent)
|    |    |    |-- other-theme (ignored/untracked)
|    |    |    +-- modified-theme (unignored, added to main project repo)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

もちろん、VCS内からどのプラグインやテーマがプロジェクトの一部であるかを追跡する機能は失われますが、実際にはバックアップ目的でのみ必要であり、とにかく何らかの通常のバックアップシステムを使用します。

ですから、これに本当に欠けている唯一のものは、FTPを使用してすべてを手動でコピーすることなく、スタック全体を別のサーバーに簡単に展開できることです。誰もそれについて考えていますか？

OK、ここでマークジャキースの講演を見て、多分私は間違った道を進んでいます。ここにすべてを追跡する別の突き刺しがあります。

   root (main project repo)
    |-- wordpress (repo as subtree)
    |-- wp-config.php (ignored/untracked)
    |-- wp-content 
    |    |-- plugins
    |    |    |-- my-custom-plugin (repo as subtree)
    |    |    |-- other-plugin-with-git-repo (repo as subtree)
    |    |    +-- plugin-without-git-repo
    |    |-- themes
    |    |    |-- my-custom-theme (repo as subtree)
    |    |    |-- other-theme-with-git-repo (repo as subtree)
    |    |    +-- theme-without-git-repo
    |    +-- uploads (ignored/untracked)
    +-- other-files.txt

これの主な欠点は、カスタムコンテンツディレクトリを持っていることだと思います。これは、以前はプラグインやテーマが不十分に書かれていて、コンテンツディレクトリが見つからないという問題を引き起こしていました。