3

ビルドが成功した後、ソース管理のコミットを自動化することは適切なポリシーですか?


編集: v1.0 と v1.1 の間で 2,000 以上の新しいコード行をロールバックするよりも、バグが導入されたポイントを簡単に見つけることができるように、バージョン間でより頻繁にインクリメンタル コミットが必要なためです。

4

2 に答える 2

5

いいえ。ビルドの成功は、コードの変更の成功を意味するものではありません。コードをテストしたことはありませんか? なんらかの自動化された単体テストがあれば、質問を理解することができました (ただし、それでもお勧めしませんが、機能を自分で確認するまでコード変更をテストしたとは考えません)。しかし、ビルドが成功した後の自動化されたコミットは、チームメイトが好きな場合や、彼らが武器にアクセスできる場合ではありません.

于 2010-12-21T09:24:19.113 に答える
4

いいえ。意味のあるコミット メッセージはどこから来るのでしょうか? 課題トラッカー アイテムへの参照はありますか? 自動化されたプロセスは、特定の作業が完了したことをどのように認識するのでしょうか?

このようなプロセスが整っていると、レポジトリは美化された IDE 取り消しバッファに劣化します。

于 2010-12-21T09:40:23.813 に答える