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リポジトリが混在しているため、明確な分離はまだありません。この問題の回避策を探しています。