バージョン管理システムが保持しているコミット履歴を使用しても、ほとんど費用はかかりません。ただし、主要なプロジェクトのリファクタリング(または再編成/クリーンアップ)の作業中に、関数とクラス、さらには名前空間も移動されます。いくつかのファイルが一緒にマージされ、他のファイルが分割される場合があります。これらの変更により、いくつかのファイルの元のコミット履歴が失われることがよくあります。
私の意見では、プロジェクトの組織を維持することは、ソースコードの履歴を保持することよりも重要です。優れたプロジェクト編成により、合理的な労力で新機能を継続的に追加できますが、ソースコードの履歴の価値は疑わしいようです。
さらに、単体テストを使用すると、回帰の問題が迅速に特定されます。最新バージョンがすべてのソフトウェア要件を満たしている限り、実際にソースコードの履歴を保持する必要がありますか?
メジャーバージョンアップグレードを実行せずに顧客にサポートを提供する必要があるため、出荷されたソースコードを保存する必要があることを理解しています。しかし、これとは別に、ソースコードコミットの履歴を保持することに何か価値はありますか?
ソースコードのコミット履歴は、チームメンバー間のコミュニケーションに何らかの役割を果たしますか?コミット履歴を廃止し、代わりに「ソースコード」+「ユニットテストコード」に依存して通信した場合はどうなりますか?
コミット履歴の存在は、主要な設計/要件の変更やそれらの変更を推進した一連の思考など、プロジェクトに関する重要な情報の長期的な文書化に満足しますか?
These changes often lead to the loss of the original commit history of a few files.
「git blame」などをご覧ください-何も失われません。見つけるのが少し難しいかもしれませんが、常にそこにあります。