Gitリポジトリと本番Webサイトを壊さずにDrupalコアをアップグレードするためのベストプラクティスは何ですか

すべてのコードがmasterブランチにあるGitリポジトリがあり、以前はすべてのDrupalファイルを無視していたので、自分が書いた（または変更した、または変更する可能性のある）コードとコードを厳密に分離していましたDrushなどで生成できます。

Drupalをアップグレードするまで、これは良い戦略のように思えました。物事がうまくいかなかった場合にロールバックできるようにしたいこと、そしてそれを行うためにGitよりも優れたツールを使用したいと思いました。私はこれが機能ブランチに最適な状況だと思ったので、drupal-7.14ブランチを作成し、.gitignoreすべてのコードと設定ファイルを無視し、Drupalインストールの一部であるファイルのみに注意を払うようにしましたtに触れる。手動でアップグレード（ダウンロード、解凍、解凍、コピー）を行い、robots.txtや.htaccessのような境界線のケースをソートし、Drupalの.gitignoreを自分で上書きしました。500エラーから回復するために、7.14では機能したが7.15では機能しなかった設定をいくつか修正したところ、すべてが完璧に見えました。ブランチの名前を変更drupal-7.15し、途中で幸せに行こうとしていました。

誤って行ったことに気付くまで：以前はマスターブランチで追跡されていなかったが作業ディレクトリに残っていたファイルは、追跡されていないファイルではなくなったため、マスターをチェックアウトすると作業ディレクトリから削除されました！ ど！

drupal-7.15ブランチをマスターにマージすると、コードの分離が失われます。

おそらくブランチをサブモジュールに変換する方法がいくつかあります。それが可能だと仮定すると、それが最良の戦略かもしれません。これを行う前に、サブモジュールが「正しい」ソリューションであることを知っていましたが、以前に追跡されていないファイルにブランチを使用することの副作用に気づかなかったため、角を切ってそのルートに進むことにしました。（また、Drupalでサブモジュールを使用する際に見たすべてのアプローチは、新しいプロジェクトを開始し、Drupalがマスターブランチになることを前提としています。他の人のコードをマスターブランチにすることは望ましくありません。マスターブランチを備えたレポ。これは、アップグレードを行うだけでは不必要に複雑になるように見えました。）

私が考えていない他の解決策があるかもしれません。

可能な限り少ない欠点でこれから回復するにはどうすればよいですか？

更新：これは開発中（私のラップトップ上のLinux VM）であり、まだ実稼働には至っていません。本番環境に移行する頃には、すべてを機能モジュールでラップする予定ですが、それはまだ整っていません。

更新2：サブモジュールが機能しない場合があります。Pro Gitによると、「サブモジュールを使用すると、Gitリポジトリを別のGitリポジトリのサブディレクトリとして保持できます」。Drupalはこのような素晴らしい分離を提供しません。すべてのDrupalコードがサブディレクトリにあるのではなく、関係は多かれ少なかれ逆になっていますが、.htaccessとrobots.txtを編集している可能性があるため、コードとDrupalリポジトリが混在しているため、明確な分離はまだありません。この問題の回避策を探しています。

上記の議論から、あなたの質問はgitリポジトリを修正することではなく、Drupalサイトをgitで維持することと、それがコアアップデートでどのように機能するかについてのようです。

実際のところ、標準的な慣行では、Drupalコアを含むすべてのファイルをリポジトリに保持していると思います。Drupalコードをカスタムコードから分離するのは良いアイデアのように思えますが、それが必要だとは思わず、どのような利点が得られるかわかりません。また、コアにパッチを適用したくない（またはデプロイの一部としてパッチを適用する必要がない）と想定しているようです。生産中。コミットを適切かつ集中的に保つことは、この種の分離を得るのにも役立ちます。

私が使用した解決策は、すべてのコードを同じリポジトリに保持し、機能またはその他の種類のエクスポート/コード/構成に可能な限り配置し、外部に適用する必要があるパッチのリストを維持することです-boxコアとcontrib。

コアを更新したら、開発環境で開始します。

• 作業ディレクトリがクリーンであることを確認してください
• 最新のデータベースをダンプします（drush sql-dump）。ダンプを使用してコミットするか、安全な場所に保存してください。
• コアを更新（drush up drupal）
• すべての変更をコミットします。
• パッチファイルを確認します。パッチを適用する必要がある場合は、それらを適用し、別のコミットを行います
• 必要に応じてupdate.phpを実行します（更新にdrushを使用した場合は既に実行されています）
• 開発サイトをテストします。すべてが正常であれば、コードを実稼働環境にプッシュします。drush updb実動で実行します。
• 問題があり、元に戻す必要がある場合は、レポジトリを元に戻すかリセットする（git reset --hard HEAD~2実行する必要があります）か、履歴を保持する場合は2つのコミットを元に戻します。データベースをダンプで置き換えます。

そうしないと、更新によってデータベースに加えられた変更を元に戻すことができないため、データベースダンプが必要です。ブランチで更新を行うこともできます。その場合、元に戻すとはマスターをチェックアウトすることを意味します。1つの開発サイトで作業している場合は、データベースのせいで実際にマスターに切り替えて並行して作業を続けることができないため、少しお勧めできません。

このよりシンプルなgitサイドワークフローを使用すると、サブモジュールなどの複雑さなしに、必要なときにgitのフルパワーを使用できます。これが適切でないようであれば、コードをさらに分離する必要がある理由を説明してください。

上記の私のコメントから、あなたが持っているこの質問は、Drupalサイトファイルの維持に関するものです。 gitでをことと、それがコアアップデートでどのように機能するかについてです。データベースのバックアップとアップグレードについては何も言及していませんでした。goron answerから何もコピーしないようにします。

この問題に関するブログ投稿を作成しました 。Gitを使用してWebサイトのDrupalコアをアップグレードする

代替方法

1. Drushコマンドを実行 drush up drupal
2. バージョン間の違いのパッチを適用します。http://drupal.org/node/359234およびhttp://fuerstnet.de/en/drupal-upgrade-easierを参照してください

これは述べていませんでしたが、Drupalバージョン間の変更を追跡することに興味がある場合は、branchの代わりにタグを使用してこれを行います。masterへのアップグレードコミットが完了したら、コードに7.xのタグを付けます。

OPと同じように2つのブランチでセットアップを実行しています。1つはカスタムコードのみを使用したブランチ、もう1つはカスタムファイルとコアファイルの両方を使用したブランチです。私は同じ状況に遭遇しました。ブランチを切り替えると、無視されたコアファイルが削除されます。

最終的に、2つの同一のgitディレクトリが作成されました。このディレクトリ内でのみブランチの切り替えとマージを実行します。

この2分岐セットアップを選択する理由は、コアファイルへのすべてのローカルコミットを簡単に追跡したいためです。コアファイルをアップグレードするときに、コアmodを調べて再適用するのが簡単です。