タグ付けされた質問 「version-control」

コンピュータファイルとして保存されているドキュメントやその他の情報に対する変更の管理に使用します。


2
Drupalコアにパッチをどのように提供しますか?
この投稿を改善してみませんか?この質問に対する詳細な回答を提供します。これには、引用と、回答が正しい理由の説明が含まれます。詳細が不十分な回答は編集または削除される場合があります。 Drupalコアにパッチを提供する適切なプロセスは何ですか? Drupalコアにバグを見つけて修正し、パッチを作成するとします。どうすれば提出できますか? バグがDrupal 7にある場合、Drupal 8でも修正して、2つのパッチを提出する必要がありますか?これはドキュメントのバグ/改善にも適用されますか? すべてのパッチにも単体テストが必要ですか?

4
DrupalサイトがSA-CORE-2018-002 — 2018年3月のエクスプロイトで構成されているかどうかを確認するにはどうすればよいですか?
リリースされたばかりのエクスプロイト:https : //www.drupal.org/sa-core-2018-002 --- Drupalコア-非常に重要-リモートコード実行-SA-CORE-2018-002 誰かがこのエクスプロイトを使用して自分のサイトをハッキングしたかどうかを確認するにはどうすればよいですか? 適切に実行された場合、このエクスプロイトで何ができますか? 現在、Drupalサイトを更新できません。この穴を簡単にパッチするための良い代替手段は何ですか?

4
「drush rsync」対「git」を使用して開発->製品をステージングすることの利点
開発作業のために、gitの管理下にあるDrupalサイトをセットアップしました。 これは、マスターのベアGITリポジトリを親とし、変更がさまざまなプロジェクト作業gitクローンで行われ、マスターにプッシュバックされると、更新後のフックがすぐに単一のライブステージングWebサイトに変更をプッシュします(http:/ /staging.loc。)。特別なことは何もない、期待どおりに動作します。 また、サイト "@STAGING"をドラッシュエイリアスしました。場合によっては、変更をステージングサイトから運用サーバーに昇格させたいと思います。 2つの比較的簡単な方法が思い浮かびます: (1)ステージングサイトが安定しているように見える時点で、マスターリポジトリからのgitチェックアウトとして本番サイトを作成します。 (2)ステージングサイトから本番サイトにdrush rsync+ drush sql-syncを使用します。 どちらも機能させることができます。(2)本質的にDrupal中心/認識であるという事実以外に、drushは、結局のところ、Drupal固有のツールのセットです-2つのアプローチの相対的なメリットは何ですか? (2)よりも(1)を考慮する必要がある特別な理由はありますか? どちらの場合も、「すべて」はリビジョン管理の少なくとも1つのインスタンスの下にあります...

4
「drush make」モジュールをローカルモジュールコードで使用するにはどうすればよいですか?
「drush make」が提供するワークフローが気に入った。drupal.orgの準備ができていない状態で開発コードをmakeファイルに入れたいと思う人もいると思います。たとえば、bashスクリプトを使用してサイトの新しい開発テストインスタンスをすばやくデプロイしたり、 Aegirで見ました。 これに適した現在のワークフローは、開発コードのgitリポジトリを利用することです。しかし、私の開発マシンはWindows 7であり、Ubuntuサーバーインスタンスの仮想ボックスで「drush make」を使用したいと考えています。

9
makefileを介してDrushで新しいモジュールを有効にする方法
職場では、新しいサイトをgitで設定し、ローカルで開発することに移行しています。これまでのところ、インストールプロファイルと一緒にDrush Makeファイルを作成しました。これをパペット経由でスクリプト化したので、ユーザーがリポジトリの新しいクローンを作成すると、すべてのパッケージがダウンロードされ、基本的なサイトインストールが実行されます。これは問題なく動作します。 さて、私の質問は、サイトに新しいモジュールを使用する必要がある場合です。たとえば、サイトの新しいモジュールを作成します。他の開発者にgitからプルして新しいモジュールを自動的にインストールしてほしい。それをdrush makeファイルに追加すると、ダウンロードのみが行われ、「drush si」を実行すると、サイトが再インストールされ、すべてのデータが消去されます。 これを達成するための最良の方法は何ですか? 編集する 私はこれを適切に説明していません。drushのmakefileエントリに基づいてモジュールを自動的に有効にする方法を探しています。アイデアは、ユーザーがプロジェクトをチェックアウトし、settings.phpファイルが存在しない場合はパペットに「drush make」と「drush si」を実行させることです。私が理解する必要があるのは、ユーザーが次にプルを実行し、新しいモジュールを追加したときに、スクリプトによってそれを自動的に有効にする方法です。必要な場合は、makefileを解析して「drush en」を手動で実行するために何かを書く必要がありますが、これを行うために事前にビルドされたものを見つけたいと思います。

2
default.settings.phpを設定して、開発、テスト、本番サイトで使用するにはどうすればよいですか?
Drupal 7サイトのセットアップにdev、tst、prd環境を使用しています。バージョン管理にはgitを使用しています。 サイトをdevからtstに、およびtstからprdに移動するときに行う必要がある手動の手順を1つ削除したいと思います。 ここで、dev、tst、prdサイトのsettings.phpを個別に更新する必要があります。 default.settings.phpファイルを設定して、dev、tst、prdのすべての設定が1つのdefault.settings.phpに保存されるようにしたいと思います。Drupalは、settings.phpにコピーした後、環境に応じて適切な設定を選択します。 以下の疑似コードのようなものを探しています: common.settings if environment = dev then ... dev.settings ... else if environment = tst then ... tst.settings ... else if environment = prd then ... prd.settings ... end if Drupal 7でこれを行う方法を正確に知っていますか?

2
SVNを壊さずにdrushでモジュールを更新していますか?
右、これは2日間私を壊しています。どこにも答えられない! サーバーにDrush 4.4があります。Unfuddle.com経由でSVNを使用しています。私はサイトを持っています。たくさんのモジュールを更新したいと思います。コードだけを更新してから、機能していることを確認し(DBの更新は現時点では問題ではありません)、関連するコードをコミットします。 以前は、drush dlがモジュールコードを削除せずに、単に古いモジュールの上からダウンロードするだけでした。それはもはやそうではありません。今、AFAICT、drushはモジュールディレクトリを削除し、新しいバージョンに置き換えます。更新されたモジュールに残っていない古いファイルの問題が解決されるため、これで問題ありません。 ただし、drush dlまたはupcコマンドを使用すると、これらのコマンドを実行すると実際に新しいバージョンが取得されるため、行き詰まっていますが、プロセス内のSVNデータフォルダーが破壊され、「!module / file.php」問題がもう存在しないファイル。 「drush upc / dl modulename --version-control = svn」は機能するはずですが、機能しません。SVNデータはまだ破壊されています。 これにより、svn del module、svn commit -m "Removed module"、drush dl module、(test the module)、svn add module、svn commit -m "Added module"-すべての場合の潜在的な悪夢が残りますモジュール、それは完全な恐怖です。 変更を自動コミットするようにDrushを設定したくありません。変更に満足したときに、それらをダウンロードしてすべて手動でコミットしたいだけです。これは難しいことではありませんが、私はそれを機能させることができません。 gitへの移行(そう、私はunfuddleがgitをサポートしていることを承知しています!)も解決策であるとアドバイスされていますが、すぐには解決できず、現時点では満足のいくものではありません。 誰かがこれにいくつかの光を当てることができますか?!

2
ビューを製品として機能としてエクスポートした後、データを(のみ)プロダクションサイトからテストサイトにコピーするためのベストプラクティス?
Drupal 7サイトを構築/テストした後、それを製品サーバーにデプロイし、すべてのビューを機能としてエクスポートしました。現在、ビューはすべてテストサイトでは「データベース内」にありますが、ライブサイトでは「コード内」です。ここで、開発の新しいフェーズのために、テストデータベースにコードデータベースではなく製品データベースをコピーしたい場合、開発サイトの「データベース内の」ビューを上書き(または消去)するのを避けるための最良の方法は何ですか? フィーチャーを作成するときにビューの名前を変更する必要がありますか? テストから/へ、または製品からテストへ、ビューをエクスポート/インポートしますか? sqldumpをコピーして戻すときに、テストデータベースのビューを選択的に保持する他の方法はありますか? どうもありがとう!


2
sites / default / files / configの.gitignoreファイルを変更します
私はDrupal 7の新しい構成管理モジュールを調べています。これは事実上、D8にある新しい構成管理のバックポートであり、構成を格納するためのフィーチャーの使用に代わる優れた方法になるようです。 https://drupal.org/project/configuration モジュールで遊んでいるテストgithubリポジトリがあります。このリポジトリにコードと構成を配置したいと思います。また、構成ファイルのデフォルトの場所(sites / default / files / config)を保持したいと思います。 これは.gitignoreDrupalよりもファイルに関する質問の方が多いことを理解しています。しかし、.gitignoreリポジトリに構成ファイルを追加できるようにファイルを変更するにはどうすればよいですか? 現在のgitignoreはこちらです。(これは.gitignoregithubがDrupalプロジェクトのデフォルトとして提供する優れたファイルです)。 !sites/default/files/config/*ファイルの最後に追加するという単純な変更は役に立たないようです。 編集:私もこれを試しましたが、運がありませんでした: !sites/default/files/config/*.inc 他の人がこの問題をどのように解決するかについてのヒントに感謝します。ありがとう!

3
提供されたモジュール機能のオーバーライド
寄稿したモジュールを少しハックして、必要な機能を少し追加する必要があります。これは通常、モジュールのメンテナがおそらく使用したくないプロジェクトに固有の機能です。 現在、私はすべてのハックのためのパッチファイルを作成し、そのようなパッチファイルをすべてsite / all / modulesに保存しています。このようにして、モジュールを更新するときはいつでも、ハックを簡単に再適用して競合を解決できます。 どうしようもない気がします。私ですか?

4
どのようにしてMakeファイルにDevモジュールを含めますか?
Drushのmakeファイルを使用して、サイト開発を自動化しています。 このチュートリアルに従って、 DrushでMakeファイルを作成しました。 メイクファイルを実行したときを除いて、すべてが正常に動作しますが、Drushはモジュールの開発バージョン(Devバージョンを使用したモジュールの場合)が見つからないと言っています。 このチュートリアルによると、これはモジュールのGitアドレスとリビジョンIDを指定する必要があるためです。どうやってやるの? 私がとったステップ たとえば、Fencesモジュールの7.x-1.x-devリリースを含めたいとしましょう。この開発モジュールは2013年9月30日にリリースされました。 プロジェクトページには、[すべてのリリースを表示]というオプションがあります。ただし、このページでは、2013年9月30日付けのリリースはありません。プロジェクトページには、プロジェクトのGitページへのリンクもあります。ただし、最新の更新は15か月前だったため、しばらく更新されていないようです。 この開発モジュールのGitアドレスを見つけるにはどうすればよいですか?それをメイクファイルに含める別の方法はありますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.