ファイルの履歴を保持するためにSubversion、Git、または同様のバージョン管理システムの使用を開始しますか？[閉まっている]

これは表面的には広範な質問かもしれませんが、WordPressサイトで編集済みファイルのバージョン履歴を保持するために使用するセットアップ/ワークフローの具体例を探しています。たとえば、サイトを開発するとき（そしてライブになった後でも）、私はしばしばCSSファイルとPHPファイルに変更を加えますが、それらのファイルの古いバージョンに戻す素晴らしい方法はありません。私の目的では、ローカルの開発インストールで変更を行ってから、それらの変更をライブサイトにコピーすることは、私が望んでいるよりも多くのトラブルです。バージョン管理ツールを使用してライブサイト上のファイルの編集を追跡する方法についての提案はありますか？

バージョン管理の使用についてどれだけ知っているかはわかりませんが、最近SVNからGitに切り替えて、すばらしいことがわかりました！

ライブサイトのサーバーにGitがインストールされている（または使用できる）かどうかにもよりますが。ライブサーバーにもGitをセットアップし、のようなブランチから実行していproductionます。ローカルで実装/修正を完了するたびにproduction、それをブランチにマージし、ライブサイトのサーバーにSSHで接続して、変更を取り込みます。変更を上書きするかどうかわからない場合に、FTPを介してファイルをドラッグするよりも優れています。

Gitに慣れるのに少し時間をかけることをお勧めします（まだ行っていない場合）。どこでも.svnフォルダ）。

私はMacを使用しているので、これらのいずれにも該当しない場合は申し訳ありませんが、Codaをコードエディターとして使用し、Portsを使用してGitをインストールしました（Porticusを使用）。

すべてを新しく設定する場合、次のようにします。

1. Codaをインストールする

2. Porticusをインストールします（Portsをインストールする必要がありますが、そのページに情報があります）

3. Porticusをインストールしたら、開いて開き、「git-core」を検索してインストールします。

4. GitX 7-5をダウンロードしてインストールする

5. gitリポジトリの設定に関する優れたガイドがここにありますが、基本は次のとおりです。1.ターミナルを開きます。2. cdサイトを配置する場所へ。$: mkdir mysite && cd mysite3. $: git initそれだけです！このフォルダーにファイルを追加する場合は、次の手順に進みます

6. GITリポジトリをローカルに設定した後（上記）、GitXでそのディレクトリを開くと、他のものをコミットできるようになります。

サーバー上ですべてを設定するのは少し難しいかもしれません。MediaTempleとDreamhostアカウントがあり、どちらもすぐにGITを使用できます。手順5のリンクは、リモートリポジトリを追加する方法を示しているため、ライブサイトを方程式に組み込むまで、リモートリポジトリを追加する必要はありません。最初にすべてをローカルで動作させることをお勧めします（SVNとは異なり、GITはリモートリポジトリを必要としないため、当面はマシン上ですべてを実行できます）。

WordPress開発で行うすべてのことで、バージョン管理にSVNを使用しています。プラグイン開発にSVNが必要だったので、実際にこの方法で始めました...そこで始めた後、クライアントサイトでテーマとカスタムスクリプトにSVNを使い続けるのは自然な拡張でした。

プラグイン

プラグインはすでにWordPressのサーバーでホストされている/wp-content/plugins/ため、ローカルのWordPressインストールのディレクトリに直接プラグインをチェックアウトするだけです（開発ボックスでWAMPを実行しています）。次に、ローカルコピーを変更し、ショータイムの準備ができたらリポジトリにコミットします。そこではスムーズなプロセスであり、アップロード/ダウンロードがなく、変更が機能したことを即座に確認できます。

テーマ

特にクライアント向けに構築する場合、テーマは少し異なります。ローカルリポジトリを作成し（Rこの目的のためにハードドライブにパーティションを作成しています）、空のリポジトリを直接/wp-content/themesディレクトリにチェックアウトします。次に、必要に応じて変更を加え、準備が整うまで開発し、進行中にリビジョンをコミットします。

テーマをクライアントの実稼働サーバーに公開する準備ができたら、リポジトリをエクスポートして圧縮し、WordPress内のネイティブテーマ>>新しい機能を追加します。これは（WordPressでホストされていない）カスタムプラグインでも機能します。

道具

先ほど言ったように、ローカルマシンでWAMPを使用してWordPressの開発インストールを実行します。それは私のボックスで完全に動作し、特定のプロジェクトに必要なだけのWordPressのインスタンスを実行することができます。

SVNの場合、Tortoise SVNを使用します。無料で、非常に使いやすく、Windowsのファイルおよびコマンド構造と統合されています。更新、コミット、およびエクスポートはすべて、単純な右クリック、選択コマンド操作です。「エクスポート」を使用すると、フォルダ全体を（迷惑な.svnフォルダなしで）任意の場所に直接送信できます-私は頻繁にデスクトップにエクスポートします。フォルダの圧縮も右クリック操作であり、WordPressはアップロードを処理します。

手動でファイルを転送することは、特に1つのファイルを変更し続けてもすべてのファイルを変更する場合は面倒です。代わりに「すべて上書き」を選択してディレクトリ全体をFTP転送すると、古いファイルを簡単に置き換えることができます（変更されたものとされなかったものを追跡する必要はありません）。これは、WordPressが以前使用していた5分間のインストールのようなものです。すべてを新しいバージョンに置き換えるだけです。

個人的には、SVN / GITをインストールして管理するのは楽しい練習だと思いますが、月額15ドルを振ることができれば、Beanstalkはすべての価値があります。彼らはあなたのためにサーバー全体を管理します。 http://beanstalkapp.com/ FTP展開ツールは素晴らしいです。たとえば、コミットすると、バージョンがステージングサーバーに自動的に展開されます

パーソナルファイルのバージョン管理を行うもう1つの方法は、ドロップボックスを使用することです。ファイルをDropboxに保存するたびにバージョンが追跡され、後で以前のバージョンに復元できます。あなたと他の開発者またはグループは、ドロップボックスフォルダーを共有できます。これはトランクやマージなどを実行しませんが、分散したチームが1つのWebサイトで作業することを非常に簡単にします。まったく同じファイルを一度に実際に操作することはできません。

SVNの作業コピーをDropboxに保存し、書き込みが完了したらファイルをコミットします。私のデザイナーはファイルをコミットしたりSVNを処理したりしないので、これは妥協です。

SVNが好きなのは、GITが非常に優れているトランキングをすべて必要とせず、SVNの優れたGUIツールがあるためです。

私はAptanaが大好きで、Subversionが統合されており、ftp / sftpで簡単にサーバーに接続してファイルをプッシュアップできます。もう1つの優れた機能は、新しいphpプロジェクトを作成して「完全な」WordPressフォルダ（wp-admin、wp-includesを使用）を使用すると、テーマファイルでコード補完が行われます。

私の設定では、リポジトリはローカルです。

「しかし、WordPressサイトで編集されたファイルのバージョン履歴を保持するために使用するセットアップ/ワークフローの特定の例を探しています」が、製品についても言及しています。

ツールのリストといくつかのベストプラクティスの答えとして上記のようになりますが、ここではワークフローに焦点を当てます。これらはワードプレス固有のものではありません。

ただし、一般的な例/セットアップ/ワークフローの場合：

まず、CMパターンがあるため、ツールとは無関係です。Google on CM Patterns、多くの本、Wikiのコミュニティ（例：http : //www.cmcrossroads.com/forums）。

有効なストリーム戦略（Googleストリーム戦略）などの設定に関するガイドもあります...

大規模なSiebel、SAP、Informatica、Javaなどの工場での分散並列開発を含むCM Managementと比較して、WordPressの展開について特別なことはないと思います。ほぼデフォルトです。

欠けているのは、WordPress開発用のCMplan（まだ）（IEEE）を誰も書いていないことだと思います。誰かがそれを行ったら（ツールに依存しない）。要件はどのツールでも満たすことができると思います。

計画が書かれていないのは、ほとんどすべてのWordPressの実装が1人で簡単な開発-生産セットアップで行われているため、ビルドフェーズで複数の開発者/デザイナーが実行されている異なるバージョンを展開する必要がないためだと思いますたとえば、テスト環境。

つまり、CMPプランはすべてのCIの特定から始まります。つまり、アプリ、プラグイン、データベース、ドキュメント、ヘルプ、コンテンツ、構成ファイル、リリースノート（！）などを含むWordPress実装に存在するすべてのCIのリストを作成します。 ..）。それは良いスタートです。次に、CMに含めるものを決定します。

次に、これらのCIの変更の原因を判断します。たとえば、顧客がバグ修正を要求したり、必要なアップグレードをしたりします。正しく行われた場合、これは物事が制御されていると感じている状況につながります。

本番環境から開発環境にマージするなどの決定とその処理方法は、この章の一部です（ここでは2つの主なパターン）（もちろん、これらの修正プログラムは最小限に抑えるようにしてください）。

後でCMを片方で実行するツール（バージョン管理をツールの1つとして含む）と、もう一方で変更管理ツール（正気を保つ）を探すだけです。

私がグーグルで調べた限りでは、誰もまだやっていなかったので、それが最初の最適なワークフローだと思います。IEEEによると、最初の人がWordPress CMプランを作成すると、世界中の他のすべてのWordPress人がそのプランをコピーして調整し、ツールのパターンを実装できると思います。

仕事が多すぎない/重すぎない：会社を持っているかどうかに依存します：良いCM計画を立てるために、いつかあなたの大きな時間を節約できます。

私は共有ホスト上にいるので、SVNなどをインストールできません。私はMercurialを使用して、自宅のマシンでバージョン管理を行っています。Beyond CompareのFTP同期を使用して、ローカルフォルダーとリモートフォルダーの同期を維持します。

私はgitを使用しています。簡単だ。クローン、コミット、プッシュ、プルなどの単純なコマンドを理解する必要はありません。準備は完了です。それが基本です。

それでも、製品を扱うチームを調整するなど、gitを使用する場合は、別のレベルになります。しかし、最終的には、gitまたはバージョン管理を使用する価値がありました。たわごとが発生したときに実現可能です。