生成されたコードをソース管理に保存する必要がありますか

これは私が参加している議論です。もっと多くの意見や見解を得たいと思います。

DB操作を処理するためにビルド時に生成されるいくつかのクラスがあります（この特定のケースでは、SubSonicを使用しますが、質問にはそれほど重要ではないと思います）。生成は、Visual Studioの事前ビルドステップとして設定されます。したがって、開発者（または公式のビルドプロセス）がビルドを実行するたびに、これらのクラスが生成され、プロジェクトにコンパイルされます。

現在、一部の人々は、これらのクラスをソース管理に保存すると混乱が生じる可能性があると主張しています。取得したコードが、自分の環境で生成されたものと一致しない場合があります。

コードが通常ブラックボックスとして扱われる場合でも、コードの履歴を追跡する方法が必要です。

引数または反対引数はありますか？

上記の理由により、現時点では承認された回答を選択しません。

ソース管理にそれを保存することは、それが価値があることよりも厄介です。

ビルドを実行するたびにコミットを実行して、値を設定する必要があります。

通常、私たちは生成されたコード（idl、jaxbなど）を私が作業するソース管理の外側に残しますが、問題はありません

ソースコード管理に配置します。作成したすべての履歴を将来の開発者が利用できるようにする利点は、同期後に時々再構築するというわずかな痛みよりも重要です。

自分の個人リポジトリでソースツリーの変更を表示するたびに、すべての「生成されたファイル」が変更され、コミットする必要があると表示されます。

私は、自動生成された変更ではなく、実行された実際の更新のみを含む修正のより明確なリストを用意したいと思います。

それらを省略し、ビルド後に、生成された各ファイルに「無視」を追加します。

このように見てください：オブジェクトファイルをソース管理にチェックインしますか？生成されたソースファイルは、オブジェクトファイル、ライブラリ、実行可能ファイルと同様にビルドアーティファクトです。彼らは同じように扱われるべきです。ほとんどの場合、生成されたオブジェクトファイルと実行可能ファイルをソース管理にチェックインするべきではないと主張します。同じ引数が生成されたソースに適用されます。

生成されたファイルの履歴バージョンを確認する必要がある場合は、そのソースの履歴バージョンに同期して再構築できます。

生成されたファイルをソース管理にチェックインすることは、データベースの非正規化に似ています。たまにありますを行う理由（通常はパフォーマンスのため）、データが非正規化されると正確さと一貫性を維持することが非常に難しくなるため、これは十分に注意して行う必要があります。

生成されたコード（または他のアーティファクト）をソース管理に追加することは避けるべきだと思います。生成されたコードが特定の入力に対して同じである場合は、比較するバージョンをチェックアウトして、比較のためにコードを生成できます。

私はDRY原則と呼んでいます。ビルド時にこれらのコードファイルを生成するために使用される「ソースファイル」がリポジトリにすでにある場合、同じコードを「2回」コミットする必要はありません。

また、たとえばコード生成がいつか壊れると、この方法でいくつかの問題を回避することができます。

いいえ、3つの理由があります。

1. ソースコードは、現在または以前の特定の時点におけるアプリケーションのスナップショットを再現するために必要かつ十分なものすべてです。これが意味することの一部は、チェックインされたすべてに対して誰かが責任を負うことです。一般的に、私が書くコードに対して責任がありますが、私が書いたものの結果として生成されるコードには責任がありません。

2. 私は、誰かが最新であるかどうかわからない中間コードを使用してプライマリソースからビルドをショートカットしようとする誘惑に駆られたくありません（さらに重要なことに、私は責任を受け入れたくありません）。それもまたそうではありません。一部の人々は、部分的なビルドに基づいて中間コードの競合をデバッグすることについて、無意味なプロセスに巻き込まれがちです。

3. ソース管理に入ると、私は責任を負います。そこにある、b。それが最新のものであり、c。そこにある他のすべてのものと確実に統合できます。これには、使用しなくなったときに削除することも含まれます。その責任は少ないほど良い。

チェックインすべきではないと思います。

確かに、生成されたコードの変更はノイズになる-環境間の変更、または他の何かの結果としての変更-たとえばDBの変更など。DBの作成スクリプト（またはその他の依存関係）がソース管理にある場合、なぜ生成されたスクリプトも必要なのですか？

一般的なルールはありませんですが、コードの生成に時間がかかる場合（DBアクセス、Webサービスなどのため）、キャッシュされたバージョンをソース管理に保存して、すべての人の負担を軽減することができます。

ツールもこれを認識し、必要に応じてソース管理からのチェックアウトを処理する必要があります。ツールが多すぎると、理由もなくソース管理からチェックアウトすることになります。
優れたツールは、キャッシュされたバージョンを操作せずに使用します（またはファイルのタイムステップを変更しません）。

また、人々がファイルを変更しないように、生成されたコード内に大きな警告を入れる必要があります。上部の警告は十分ではなく、数十行ごとに繰り返す必要があります。

生成されたDBコードも保存しません。生成されているため、ソースファイルから任意のバージョンで自由に取得できます。それを格納することは、バイトコードなどを格納するようなものです。

ここで、特定のバージョンで使用されるコードジェネレーターが使用可能であることを確認する必要があります。新しいバージョンは異なるコードを生成する可能性があります...

はなれる。

生成されたファイルをチェックインしている場合は、何か問題があります。何が悪いのかは異なるかもしれません、それはあなたのビルドプロセスが非効率的であるか、何か他のものかもしれませんが、私はそれを今まで見ることができませんは良いアイデアであること。履歴は、生成されたファイルではなく、ソースファイルに関連付ける必要があります。

違いを解決して、ビルドで生成されなくなったファイルを見つけ、それらを削除しようとする人々にとって頭痛の種になるだけです。

生成されたファイルをチェックインする人には、苦痛の世界が待っています！

生成されたファイルをチェックインする特別なケースがあります。他のファイルの生成に使用されたツールが利用できないシステム上でビルドする必要がある場合です。この典型的な例、および私が作業しているものの1つが、LexおよびYaccコードです。多種多様なプラットフォームとアーキテクチャでビルドおよび実行する必要のあるランタイムシステムを開発しているため、CおよびC ++コンパイラを使用できるのはターゲットシステムのみであり、インターフェイス定義の字句解析/解析コードの生成に必要なツールではありません翻訳者。したがって、文法を変更するときは、生成されたコードをチェックインして解析します。

少し遅れて到着しました...とにかく...

コンパイラの中間ファイルをソースバージョン管理に入れますか？コード生成の場合、定義上、ソースコードはジェネレーターの入力ですが、生成されたコードは「実際の」ソースとビルドされたアプリケーションの間の中間ファイルと見なすことができます。

だから私は言うでしょう：生成されたコードをバージョン管理下に置かず、ジェネレータとその入力を配置します。

具体的には、私が作成したコードジェネレーターを使用します。生成されたソースコードをバージョン管理下で維持する必要はありませんでした。ジェネレーターが特定の成熟度レベルに達したため、入力（たとえば、モデルの説明）が変更されても、生成されたコードの内容を観察する必要はなかったとも言えます。

一部のプロジェクトでは、生成されたコードをソース管理に追加しますが、それは実際に依存しています。私の基本的なガイドラインは、生成されたコードがコンパイラーの組み込み部分である場合、追加しません。この場合、生成されたコードがSubSonicなどの外部ツールからのものである場合は、ソース管理に追加します。コンポーネントを定期的にアップグレードする場合、バグや問題が発生した場合に備えて、生成されたソースの変更点を知りたいです。

生成されたコードをチェックインする必要がある限り、最悪のシナリオは手動でファイルを差分化し、必要に応じてファイルを元に戻すことです。svnを使用している場合は、svnにpre-commitフックを追加して、ファイルが実際に変更されていない場合にコミットを拒否できます。

構成管理（バージョン管理は一部にすぎません）の仕事は、次のことを実行できるようにすることです。

• 提供されたすべてのビルドにどの変更とバグ修正が行われたかを把握します。
• 元のソースコードから始めて、提供されたビルドを正確に再現できるようにします。自動生成されたコードは、言語に関係なく「ソースコード」としてカウントされません。

1つ目は、クライアントまたはエンドユーザーに「先週報告したバグが修正され、新機能が追加された」ことを伝えると、2時間後に戻って「いいえ」になっていないことを示しています。また、「なぜXを使用するのか？Xを要求したことは決してない」と言わないようにします。

2つ目は、クライアントまたはエンドユーザーが1年前に発行した一部のバージョンのバグを報告したときに、そのバージョンに戻ってバグを再現し、修正して、修正がバグではなくバグを排除したことを証明できることを意味しますコンパイラーの混乱やその他の修正。

つまり、コンパイラ、ライブラリなどもCMの一部である必要があります。

だから今あなたの質問に答えましょう：上記のすべてを行うことができれば、とにかく同じ答えを得ることが保証されているので、中間表現を記録する必要はありません。上記のすべてを実行できない場合、同じことを2回実行して同じ答えを得ることが保証できないため、すべての賭けは無効になります。したがって、すべての.oファイルもバージョン管理下に置くことができます。

それは本当に依存します。最終的に、目標は、必要に応じて、持っていたものを再現できるようにすることです。バイナリを正確に再生成できる場合は、バイナリを保存する必要はありません。ただし、コンテンツを再作成するには、最初に行った正確な構成が必要になる可能性があることを覚えておく必要があります。これは、ソースコードだけでなく、ビルド環境、IDE、場合によっては他のライブラリも意味します、ジェネレーターなど、使用した構成（バージョン）とまったく同じです。

ビルド環境を新しいバージョンにアップグレードしたり、以前の正確なバイナリを再作成できなかった別のベンダーにアップグレードしたりすると、プロジェクトで問題が発生しました。特にセキュリティ保護された環境で、提供されるバイナリが一種のハッシュに依存し、コンパイラのアップグレードなどにより、再作成されたファイルが何らかの形で異なる場合、これは本当に痛みです。

だから、あなたは生成されたコードを保存しますか？私はノーと言うでしょう。リリースされたバイナリーまたは成果物（私がそれらを使用して複製したツールを含む）。そして、それらをソース管理に保存する必要はありません。それらのファイルの適切なバックアップを作成するだけです。

正解は「依存する」です。それはクライアントのニーズに依存します。コードを特定のリリースにロールバックし、それなしで外部監査に耐えることができれば、まだしっかりした基盤にありません。開発者としては、「ノイズ」、痛み、ディスク容量だけでなく、知的財産を生成する役割が課せられており、法的な問題が発生する可能性があるという事実を考慮する必要があります。2年前に顧客が見たとおりにWebサイトを再生成できることを裁判官に証明できますか？

gendされたファイルを保存するか保存しないかはお勧めしません。おそらく、間違っていると判断した件名の専門家に関与していないかどうかを判断します。

私の2セント。

ここに提示された賛否両論の良い議論があります。記録のために、私はVisual StudioでT4生成システムを構築し、デフォルトの既定のオプションにより、生成されたコードがチェックインされます。チェックインしたくない場合は、もう少し努力する必要があります。

私にとって重要な考慮事項は、入力またはジェネレーター自体が更新されたときに生成された出力を比較することです。

出力をチェックインしていない場合は、ジェネレーターをアップグレードしたり入力を変更したりする前に、生成されたすべてのコードのコピーを取得して、新しいバージョンの出力と比較できるようにする必要があります。これはかなり退屈なプロセスだと思いますが、チェックインされた出力では、新しい出力をリポジトリと比較するのは簡単なことです。

この時点で、「なぜ、生成されたコードの変更を気にするのですか？」（特にオブジェクトコードと比較して）いくつかの重要な理由があると思います。これらの理由は、固有の問題ではなく、現在の最新技術に帰着します。

1. 生成されたコードと緊密に一致する手書きのコードを作成します。最近のobjファイルでは、そうではありません。生成されたコードが変更されると、悲しいことに、手書きのコードを変更して一致させる必要がある場合がよくあります。多くの場合、生成されたコードの拡張ポイントとの高度な下位互換性はありません。

2. 生成されたコードは、単にその動作を変更します。コンパイラからこれを容認することはできませんが、公平に言うと、アプリケーションレベルのコードジェネレータは、受け入れ可能なソリューションの範囲が広い別の問題分野を対象としています。以前の動作について行った仮定が今は破られているかどうかを確認することが重要です。

3. ジェネレーターの出力がリリースごとに100％信頼されないだけです。厳密にコンパイラベンダーでビルドおよび保守されていなくても、ジェネレータツールから得られる価値はたくさんあります。リリース1.0はアプリケーションに対して完全に安定していた可能性がありますが、おそらく1.1には、ユースケースにいくつかの不具合があります。あるいは、入力値を変更して、以前に使用したことがないジェネレーターの新しい部分を実行していることを発見しました。結果に驚かれる可能性があります。

基本的にこれらすべてのことはツールの成熟度に帰着します。ほとんどのビジネスアプリのコードジェネレーターは、コンパイラーやlex / yaccレベルのツールでさえ何年も前からあったレベルに近くありません。

どちらの側にも正当で合理的な議論があり、共通点について合意することは困難です。バージョンコントロールシステム（VCS）は、開発者がその中に入れたファイルを追跡し、VCS内のファイルは開発者によって手作りされたものであり、開発者は履歴とファイルの任意のリビジョン間の変更に関心を持っています。この仮定は、「チェックアウト時にこのファイルを取得したい」という2つの概念を等しくします。「このファイルの変更に興味があります。」

さて、両側からの議論は次のように言い換えることができます：

• 「このマシンでファイルを生成するためのツールがないので、チェックアウト時にこれらすべての生成されたファイルを取得したいのです。」
• 「このファイルの変更に興味がないので、VCSに入れるべきではありません。」

幸いなことに、2つの要件は根本的に矛盾していないようです。現在のVCSをある程度拡張すると、両方を使用できるようになります。つまり、これは誤ったジレンマです。しばらく考えてみると、問題がVCSが保持しているという仮定から生じていることを理解するのは難しくありません。VCSは、開発者が手作業で作成したファイルと、開発者が手作業で作成したのではなく、たまたまこのVCS内にあるファイルを区別する必要があります。通常、ソースファイル（コード）と呼ばれる最初のカテゴリのファイルについては、VCSは素晴らしい仕事をしています。後者のカテゴリーでは、VCSは私が知る限り、そのような概念をまだ持っていません。

概要

私が意味することを説明するために、一例としてgitを取り上げます。

• git status デフォルトでは、生成されたファイルは表示されません。
• git commit 生成されたファイルをスナップショットとして含める必要があります。
• git diff デフォルトでは、生成されたファイルは表示されません。

PS

回避策としてGitフックを使用できますが、Gitがネイティブでサポートしていると便利です。gitignore無視されたファイルはVCSに入らないため、要件を満たしていません。enter code here

私は主張するでしょう。コードをチェックアウトし、ビルド番号を変更し、ソフトウェアをビルドしてからテストする継続的インテグレーションプロセスを使用している場合、そのコードをリポジトリの一部として使用する方が簡単で簡単です。

さらに、ソフトウェアリポジトリから取得するすべての「スナップショット」の一部です。ソフトウェアの一部である場合は、リポジトリの一部である必要があります。

はい、あなたはそれをソース管理下に置きたいと思います。構成管理の観点からは、ソフトウェアビルドを作成するために使用されるすべてのものを再作成できるように制御する必要があります。生成されたコードは簡単に再作成できることを理解していますが、2つのビルド間で日付/タイムスタンプが異なるため、同じではないという主張をすることができます。政府などの一部の地域では、多くの場合、これが行われます。

一般に、このコードのリビジョン履歴は、それを生成したコードのリビジョン履歴で追跡できるため、生成されたコードをソース管理に保存する必要はありません。

ただし、OPが手動でコードを作成する代わりに、生成されたコードをアプリケーションのデータアクセスレイヤーとして使用しているようです。この場合、ビルドプロセスを変更し、コードをソース管理にコミットします。これは、ランタイムコードの重要なコンポーネントであるためです。これにより、開発者が異なるブランチに対して異なるバージョンのツールを使用する必要がある場合に備えて、コード生成ツールへの依存がビルドプロセスから削除されます。

すべてのビルドではなく、コードを生成する必要があるのは1回だけのようです。開発者がオブジェクトがデータベースにアクセスする方法を追加/削除/変更する必要がある場合、手動で変更を加えるのと同じように、コードを再度生成する必要があります。これにより、ビルドプロセスが高速化され、データアクセスレイヤーを手動で最適化できるようになり、データアクセスレイヤーの履歴が簡単な方法で保持されます。

多くの派生ソースをソース管理下に置くのは残念ですが、適切なビルド環境を設定するのが面倒な人や、適切なビルド環境を設定するスキルを持っていない人とリモートで作業しているためです。派生ソースは正確に構築されています。（そして、Gnu autotoolsに関して言えば、私もその1人です！それぞれ異なるバージョンのautotoolsで動作する3つの異なるシステムでは動作できません。そのバージョンのみです。）

この種の問題は、請求書を支払った人が均一なビルド環境を要求できる有料プロジェクトよりも、パートタイムのボランティアのオープンソースプロジェクトに当てはまるでしょう。

これを行うと、基本的には、1つのサイトでのみ、または適切に構成されたサイトでのみ派生ファイルを構築することになります。Makefiles（またはその他）は、それらが実行されている場所を通知するように設定する必要があり、安全なビルドサイトで実行されていることがわかっている場合を除き、ソースの再生成を拒否する必要があります。

それがソースコードの一部である場合は、だれが何を生成したかに関係なく、ソース管理に配置する必要があります。ソースコントロールに、システムを再生成せずにシステムの現在の状態を反映させる必要があります。

多くの理由で、生成されたコードをソース管理に含めます。多くの人がすでに言っていることを繰り返しますが、私がそれをするいくつかの理由は

1. ソース管理のコードファイルを使用すると、Visual Studioの事前ビルド手順を使用せずにコードをコンパイルできる可能性があります。
2. 2つのバージョン間で完全な比較を行う場合、生成されたコードが手動でチェックすることなく、これら2つのタグ間で変更されたかどうかを確認すると便利です。
3. コードジェネレーター自体が変更された場合、生成されたコードへの変更が適切に変更されることを確認する必要があります。つまり、ジェネレーターが変更されても出力が変更されない場合、コードをコミットしても、以前に生成されたものと生成されたコードの内容に違いはありません。

生成されたファイルはソースツリーから除外しますが、別のビルドツリーに配置します。

例えばワークフローは

1. 通常のソースのチェックイン/アウト/変更/マージ（生成されたファイルなし）
2. 適切な機会に、ソースツリーをクリーンビルドツリーにチェックアウトします。
3. ビルド後、監査/規制目的で存在する必要があるすべての「重要な」ファイル（「実際の」ソースファイル、実行可能ファイル+生成されたソースファイル）をチェックインします。これにより、リリース/テストスナップショットなどに関連し、日々の開発から切り離された時間増分で、適切に生成されたすべてのコード+実行可能ファイル+何でもの履歴が得られます。

Subversion / Mercurial / Git / etcには、実際のソースファイルの履歴を両方の場所で結び付けるための良い方法がおそらくあります。

双方に非常に強力で説得力のある意見があるようです。上位投票の回答をすべて読んでから、特定のケースに当てはまる議論を決定することをお勧めします。

更新：1つの決定的な答えがあると本当に信じていたので、私はこの質問をしました。すべての回答を見ると、そのような回答はないと確信できます。この決定は、複数のパラメーターに基づいて行う必要があります。他の回答を読むことは、この問題を決定する必要があるときに自問する必要がある種類の質問に非常に良いガイドラインを提供する可能性があります。