どの部分がソースコードのバージョン管理下にありますか？
Drupalコードをバージョン管理下に置くためのベストプラクティスは何でしょうか。主にコアと標準のDrupalモジュールを使用します。カスタムテーマと1つまたは2つのカスタムモジュールの開発。
私が見る限り、3つのオプションがあります。
- Drupalフォルダ全体をバージョン管理下に置きます。開発者は、Apache htdocsフォルダ内のフォルダを直接チェックアウトして、そこから移動できます。
- カスタムコード（モジュール+テーマ）のみをチェックインします。開発者は適切なフォルダでコードをチェックアウトします。
- Dockerなどをセットアップします。
必要なものに応じて、これに対処するさまざまな方法があります。最も簡単な方法は、＃1で説明した方法です（Drupalフォルダー全体をバージョン管理下に置きます）。
これにより、Gitだけでコードベースの完全な作業コピーを簡単にチェックアウトできます。欠点は、他のGitリポジトリに既に存在する多くのコードをGitリポジトリに格納していることです（つまり、Drupalコア、contribモジュールなど）。
Drupal 8の場合、コミュニティは一般的にComposerを使用して依存関係を管理し、Drupalコードベースを構築します。次に、 composer.jsonファイル（Drupal coreおよびcontribプロジェクトの特定のバージョンを指す））と、Gitリポジトリーのカスタムコードのみが必要です。詳細： https：/ /www.drupal.org/docs/develop/using-composer/using-composer-with-drupal
別のオプションは、インストールプロファイルを作成し、Drush Makeを使用することです。このメソッドは、Composer in Drupal 8を支持して非推奨になりましたが、Drupal 7プロジェクトではうまく機能します。これは1つの高度にカスタマイズされた特定のサイトではなく、類似のサイトを多数セットアップするために使用する可能性のある一般的なコード/構成に適しています。
Dockerについて-それは別の決定のようなものです。上記のオプションのいずれかを選択し、それに応じてDockerコンテナー内でコードベースをビルドする（またはボリュームにマウントする）必要があります。
Composerは推奨されるアプローチであるため、ビルドする必要があります。Drushでも、プロジェクトごとにcomposerを介してDrushをインストールすることをお勧めします。 drupal-composer が良い出発点ですDrupal setup。DrupalそしてすべてのモジュールはComposer依存関係として定義されます。
チェックインする内容は、何よりもワークフローに依存します。
Acquia、Pantheon、OpenShift、またはリポジトリがWebルートであるか、デプロイスクリプトが制限されているその他のPaaSなどのサービスにデプロイする場合、選択するが、すべてをチェックインする。かなり単純明快ですが、柔軟性も最も低くなります。
ビルドサーバーを実行する場合、drupal-composerのデフォルト設定がこれに最適です。 yourコード（モジュール、テーマ、ライブラリ）のみをチェックインします。コミットごとに、ビルドサーバーに依存関係を取り込み、コードを処理し、アーティファクトをパッケージ化して送信します。
この設定は、ワークフローに次の1つ以上が含まれる場合に最適です。
CSS/JSの前処理（SCSS、ESモジュールなど）を実行しています。マニフェストをコミットします（つまり、
package.json、bower.json）とrawファイルとサーバーがビルドを行います。特別なデプロイ手順が必要なカスタム環境（AWSなど）を扱っています。
環境は、レジストリ（Docker Hubなど）のイメージから生成されたコンテナーです。ビルドサーバーがイメージをビルドします。
Dockerは、コードのコミット方法とは関係ありません。しかしながら...
単にテーマ/モジュールを構築していて、リポジトリ設定がDrupal.orgにあるプロジェクトリポジトリのようである場合（モジュール/テーマはリポジトリ内の唯一のものです）、公式の Drupal Dockerイメージを使用できます） 開発用。コンテナーを実行し、プロジェクトディレクトリをモジュール/テーマのディレクトリとしてマウントし、モジュール/テーマを有効にして、コードの記述を開始します。いいえDrupalコアコードはホストにもリポジトリにも存在せず、モジュール/テーマのみ存在します。