0

最初の質問の例として Drupal を取り上げます。カスタムテーマとダウンロードされた多くのモジュールを備えた drupal インスタンスがあります。ソースコードリポジトリとして使用されるサーバーがあります。drupal の開発インスタンスでの作業の現在のワークフローは、変更をテストに移行します。クライアントがそれをテストし、変更が気に入ったら、本番環境に移行します。- drupal ディレクトリ全体を git に配置する必要がありますか? またはテーマ+プラグイン?それともテーマだけ?インスタンス全体を配置する利点の 1 つは、prod で変更を簡単に複製できることです。これは、dev と test と同じように見えます。

2 番目の質問は、製品のコア コードをいつローカルでカスタマイズするかということです (例として DSpace を見てみましょう)。バージョン 1.6 を取得し、ローカルで変更を行い、それらをリポジトリに保持します。その後、バージョン 1.7 がリリースされたら、それを取得して、ローカルの変更をそれにマージする必要があります。1.7 を取得するにはどうすればよいですか? 支店に入ることはできますか?

これらの状況でのベストプラクティスは何ですか。

ありがとう。

PS - 私は git ignore とそれを技術的に行う方法を知っています。私が探しているのは、ベストプラクティスに関するアドバイスです。

4

1 に答える 1

2

重要度順:

  1. プロジェクトのビルドに必要なすべてのものを Git に入れます (つまり、ビルド プロセス自体ではダウンロードされないすべての依存関係を含めます)。
  2. すべてを Git に入れ、開発者のマシンでプロジェクトを実行します
  3. 生成されたすべてのファイル (突然のバグを見つけるのに役立つことがよくあります - 別名「でも何も変更していません!」)。これらはあると便利ですが、頻繁に変更されるため煩わしい場合があります。
  4. すべての依存関係 (古いビルドを簡単に再作成できるようにするため)

私は通常、本番バージョンを Git に入れません。代わりに、プロジェクトから本番サイトを作成するスクリプトと、このサイトを展開するためのアップロード スクリプトがあります。そうすれば、新しい製品バージョンをローカルで実行できます。また、アップロード スクリプトには「古いファイルをバックアップする」ステップがあるため、古い本番サイトを数分で復元できます (データベースが何らかのバグによって破損していない限り)。

[編集]多くの人がポイント 3 と 4 に同意しません。

まず第一に (すでに上で述べたように)、これは順序付きリストです。したがって、最初の 2 点は他の点よりもはるかに重要です。

そうは言っても、生成されたファイルをバージョン管理することは依然として非常に理にかなっています。一般的なケースは、IDE プロジェクトの設定とコード ジェネレーターの出力です。

それらを再作成するのは非常に簡単なのに、なぜそれらをバージョン化するのでしょうか? いくつかの理由があります:

  1. ハードディスク容量は安価です。これにより、バグを 1 時間以内に見つけることができれば、約 100 ドル、つまり約 2 TB のディスク容量に相当します。

  2. IDE プロジェクト ファイルには、コンパイラ設定とその他の非常に重要な構成が含まれています。それらを常にバージョン管理しているとは限らない場合、最終的には次のような状況になります: ファイルはDVCSの無視リストに含まれます。問題が見つかりました (有効なはずの重要な警告など)。警告を有効にします。変更したファイルをバージョン管理に追加するのを忘れています。

    または: あなたはチームの一員です。1 か月後、チームの全員がさまざまなオプションを使用してプロジェクトを構築します。IDE で何かが警告として構成されているが、他の誰かにとってはエラーであるため、ビルドが中断します。

  3. ツールによって生成されたコードはバージョン管理されるべきではありませんか? コード ジェネレーターの構成ファイルをバージョン管理するだけでは十分ではありませんか?

    多分。もう一度質問です。このコードでバグを見つける必要はありますか? そうでない場合でも、ファイルがバージョン管理下にある場合、構成オプションの変更が何を意味するかを非常に簡単に確認できます。オプションを変更し、コード ジェネレーターを実行して、バージョン ツールに変更内容を表示させるだけです。もちろん、同様のことを手動で行うこともできますが、無料で利用できるものになぜそれほどの労力を費やすのでしょうか?

  4. 最も重要なことは、「誤ったマージ競合」が発生することです。多くの人がこれを問題だと思っていますが、そうではありません。実際、ビルドが不安定であることを意味するため、これらの問題を確認する必要があります。

    1. あなたのVCSは、ファイルが変更されるべきではないときにファイルが変更されたと言っています。それはバグではなく、恩恵です。バージョン管理がなければ、この変更は発生していたはずですが、気付かなかったでしょう。最後に無知が知識より優れていたのはいつですか?
    2. 1 つのファイルでマージの競合が何度も発生しています。これは、ビルドまたはプロジェクトのセットアップに多少の愛情が必要であることを示しています。繰り返しますが、マージの競合を解決するのは面倒です。しかし、すべての開発者が気付かずに独自のバージョンのファイルを取得する方が本当に良いですか?
于 2012-08-17T15:11:36.030 に答える