cronジョブを使用してMagentoサイトをコーディングしてバックアップを処理してきましたが、以前のバージョンのサイトに戻そうとすると少し不格好になります。基本的に、バックアップを掘り下げて手動で元に戻す必要があります。私はgitについて読んだことがあり、開発サイクルを通じて変更を文書化し、いくつかのコマンドで変更した特定のものに戻すことができるというアイデアが気に入っています。
現在、ローカルリポジトリに2つのブランチがあります（マスター、開発）。基本的に、開発ブランチですべての開発を行い、特定のタスクセットが完了したら、すべてをマスターブランチにマージし、バックアップの目的でgitbucketリポジトリにプッシュして、リモートリポジトリ。
私はgitを初めて使用するので、これは私のシナリオには十分に聞こえますか、それとも誰かがgitとMagentoを使用する一人のショップに適したワークフロープロセスを推奨できますか？ありがとう。
Magentoの開発にはGitFlowモデルを使用しています。これはあなたのものと似ていますが、ステージングサイト用の追加のブランチがあります。より大規模な開発タスク/修正も、開発が常に適度に安定していることを保証するために、別々のブランチで完了します。私たちのステージングサイトは、ステージングブランチがチェックアウトされたgitリポジトリであり、本番サイトではマスターブランチがチェックアウトされています。ステージングへの変更をデプロイする準備ができたら、それらをローカルマシンのステージングにマージし、中央のgitリポジトリにプッシュしてから、サーバーをプルします。うまく機能しますが、app / etc / local.xmlは環境ごとに異なるため、注意する必要があります。また、メディアやvarフォルダーなどがgitリポジトリに含まれないようにする必要もあります。
GithubはMagentoの.gitignoreを公開していますが、私が抱えている問題は、すべてのMagentoコアファイルが除外されていることです。最終的には、変更のみを含み、デプロイ可能なものは含まない、すてきなクリーンなリポジトリになります。基本的にメディアvarとapp/etc/local.xmlを除外するはるかに単純な.gitignoreを使用します。通常、単一のリモート（Githubなど）を使用し、そこからデプロイします。
デプロイ先のサーバーには、通常、シェルアクセスとgitがインストールされているため、デプロイは、通常のリモートからgit pull（またはフェッチとマージ）をsshで実行するだけです。
ステージングサイトをgitの個別のブランチとして維持し、同じ方法でデプロイします。したがって、私たちのプロセスは、機能ブランチで開発し、完了したら「開発」にマージするように見えます。統合テストが完了したら、「開発」（またはチェリーピックの変更）を「ステージング」にマージしてデプロイします。本番環境の準備ができたら、「ステージング」（または個々の変更をチェリーピック）を「マスター」ブランチにマージします。これは基本的にGitFlowですが、「リリースの準備」ブランチは長続きします。
コメントでリンクされているSonassiチュートリアルが指摘しているように、メディアのシンボリックリンクの問題は、メディアファイルを本番環境から削除すると、ステージングでリンク切れが発生することです。その逆も同様です。2つをリンクする代わりに、gitからステージングコードを更新しますが、それ以外の場合は、ステージングサイトと本番サイトを別々に実行します。ステージングで新しいデータが必要な場合は、何らかの理由で本番メディアとデータベースのコピーを取り、ステージングサイトに復元します。
Gitflowモデルは、リリースタグにバージョン番号を使用します。チームがリリースについて合意したバージョン番号がある場合は、それらを使用します。そうでなければ、ある種のマイルストーン計画、または作業中のスプリントシステムがあり、その方法でリリースを識別できる場合は、それも機能します。他のすべてが失敗した場合は、展開が発生した日時を使用します。例えば
git tag -a deployed-`date +%Y%m%d-%H%M` -m "Code release at `date`"