ビルドが成功した後、ソース管理のコミットを自動化することは適切なポリシーですか?
編集: v1.0 と v1.1 の間で 2,000 以上の新しいコード行をロールバックするよりも、バグが導入されたポイントを簡単に見つけることができるように、バージョン間でより頻繁にインクリメンタル コミットが必要なためです。
ビルドが成功した後、ソース管理のコミットを自動化することは適切なポリシーですか?
編集: v1.0 と v1.1 の間で 2,000 以上の新しいコード行をロールバックするよりも、バグが導入されたポイントを簡単に見つけることができるように、バージョン間でより頻繁にインクリメンタル コミットが必要なためです。
いいえ。ビルドの成功は、コードの変更の成功を意味するものではありません。コードをテストしたことはありませんか? なんらかの自動化された単体テストがあれば、質問を理解することができました (ただし、それでもお勧めしませんが、機能を自分で確認するまでコード変更をテストしたとは考えません)。しかし、ビルドが成功した後の自動化されたコミットは、チームメイトが好きな場合や、彼らが武器にアクセスできる場合ではありません.
いいえ。意味のあるコミット メッセージはどこから来るのでしょうか? 課題トラッカー アイテムへの参照はありますか? 自動化されたプロセスは、特定の作業が完了したことをどのように認識するのでしょうか?
このようなプロセスが整っていると、レポジトリは美化された IDE 取り消しバッファに劣化します。