2

私は大学院生で、主な研究対象はソフトウェア シミュレーションです。結果を生成するために使用する C++ コードがいくつかありますが、私の大きな問題は、再現性を確保するために、バイナリに十分なメタデータを保存して、そのバイナリを生成した正確なソース コードに戻ることができるようにすることです (主に、以前に生成した結果が無効になっているバグを発見したかどうかを確認するためです)。

つまり、一連の出力ファイルを生成するときに、現在のリビジョンの git commit と未処理の変更の両方をバイナリにダンプする必要があります。これにより、(理論的には)そのコミットをチェックアウトし、保存されたパッチを適用して、バイナリを作成した正確なソース コードに戻ることができます。

情報などを手動で保存することで帯域外でこれを実行できることはわかっていますが、完全な一貫性を確保するために、情報をバイナリに直接焼き付けて、すべてのバイナリを追跡できるようにしたいと考えています。その正確なソース。

私はメイクファイルに #define フラグを設定して git commit SHA1 のようなものを保存することには慣れていますが、git diff 全体を文字列としてバイナリに保存するための、より賢い方法が必要だと思います。

だから私はいくつかの質問があります:

  1. これはひどい考えですか?バイナリをソースまでトレースするためのより良い方法はありますか?
  2. これを達成するための最適な方法は何ですか?

ありがとう。

編集:差分を保存する理由は、現在のHEADの上にコミットされていない変更をキャプチャするためであることを明確にしていないと思います。ハッシュを保存することはできますが、コミットされていないものをラップしてバイナリを使用するというミスを犯した場合、正しいソースを取り戻すことができません。

4

4 に答える 4

3

コードに git "id" 番号 (ハッシュ) を保存することは悪い考えではありません。差分を保存しても意味がありません。ハッシュが (元のブランチと共に) 元のコードに戻れるはずだからです。

コミットされていないものを使用できないように、ビルドとテストのシステムがセットアップされていることを確認してください。そのようにして、ビルドでコミットされていないランダムな変更を行うことはできません。

編集: プロジェクトのローカル コピーでマシン上でテストすることと、すべてをチェックするテスト スイートを使用してテストすることには違いがあります。これは、すべてが機能することを確認するために使用するものですよね? 他の誰かがそのコードのコピーを取得するまで、何をテストするかは問題ではないことに注意してください。コードがコミットされるまでは、他の人にあなたのコードを見させないでください。また、テストを保存する完全なテスト スイートを許可しないでください。すべてをコミットしていない場合に実行するリリースノートなどの結果[または、さらに良いことに、中央リポジトリからのみ新しいコードを取得する別のディレクトリ/マシンを用意します-そうすると、おそらくコミットされていないコードを使用します。

私はそのように機能するいくつかのプロジェクトに取り組んできました.コミットされていないコードでローカルディレクトリにビルドできますが、すべての「公式ビルド」は別のマシンで行われ、コードは常にレポから直接、ローカルの変更はありません.

2 台のマシンがない場合、おそらく「別のマシンのように動作する」仮想マシンを使用するか、単に「公式テスト」に使用する 2 番目のディレクトリ [または別のユーザー?] を使用します。

実際には、いくつかの差分があるかどうかを確認し、「これはハッシュです」と一緒に、違いがある場合は、「-with-uncommitted-changes」などを追加するだけです。git diff --exit-code「変更なし」または「変更」の 0 または 1 の終了コードを与えるために使用できます。

于 2013-08-08T17:02:27.797 に答える
2

git SHA1 id を保存することは、達成したいことに対して技術的な観点から十分に公平です。

コミットされていない変更?それらが存在する場合は、ビルド プロセスが失敗するように設定します。
ビルド エンジニアリングが難しすぎたり、手間がかかりすぎたりする場合は、より多くの規律を示してください。:)

編集:
シェルスクリプトを介してビルドします。変更のチェックを構築する前に、git diff --exit-code役立つ場合があります。

編集 2:コードの多くのリビジョン
git help bisectをデバッグする必要がある場合に便利です。

于 2013-08-08T20:36:28.153 に答える
2

これに対する最良の答えは、「そのようにしないでください」だと思います。反復可能なビルドが必要な場合は、ダーティな作業ディレクトリではなく、コミットされた変更に対してのみビルドしてください。必要に応じて、うまくいかない場合は破棄できるサイド ブランチに実験的なものをコミットするか、リポジトリに残しておいてください (たとえば、ビルドを繰り返すユース ケースの場合)。ただし、そのブランチを破棄して作業します別の新しいブランチで。ビルドのために戻りたい特定のポイントしかない場合は、それらの特定のコミットに適切なタグをドロップすることを検討してください。

于 2013-08-08T22:05:45.367 に答える