バージョン管理のコミット履歴とリファクタリングおよびドキュメントの保存


11

バージョン管理システムが保持しているコミット履歴を使用しても、ほとんど費用はかかりません。ただし、主要なプロジェクトのリファクタリング(または再編成/クリーンアップ)の作業中に、関数とクラス、さらには名前空間も移動されます。いくつかのファイルが一緒にマージされ、他のファイルが分割される場合があります。これらの変更により、いくつかのファイルの元のコミット履歴が失われることがよくあります。

私の意見では、プロジェクトの組織を維持することは、ソースコードの履歴を保持することよりも重要です。優れたプロジェクト編成により、合理的な労力で新機能を継続的に追加できますが、ソースコードの履歴の価値は疑わしいようです。

さらに、単体テストを使用すると、回帰の問題が迅速に特定されます。最新バージョンがすべてのソフトウェア要件を満たしている限り、実際にソースコードの履歴を保持する必要がありますか?

メジャーバージョンアップグレードを実行せずに顧客にサポートを提供する必要があるため、出荷されたソースコードを保存する必要があることを理解しています。しかし、これとは別に、ソースコードコミットの履歴を保持することに何か価値はありますか?

ソースコードのコミット履歴は、チームメンバー間のコミュニケーションに何らかの役割を果たしますか?コミット履歴を廃止し、代わりに「ソースコード」+「ユニットテストコード」に依存して通信した場合はどうなりますか?

コミット履歴の存在は、主要な設計/要件の変更やそれらの変更を推進した一連の思考など、プロジェクトに関する重要な情報の長期的な文書化に満足しますか?


3
使用するソースコードシステムに応じて、ファイルの移動などが行われた場合でもバージョン履歴が保持されます。削除されたファイルの履歴にもアクセスできるはずです。そして最後に重要なのは、最終結果の履歴です。クラスXはクラスYとZの組み合わせである場合がありますが、履歴からわかるように(特に、チェックインコメントが適切な場合)、元のファイルに戻ることができます。ここに何かが足りませんか?
アダムリア

1
These changes often lead to the loss of the original commit history of a few files.「git blame」などをご覧ください-何も失われません。見つけるのが少し難しいかもしれませんが、常にそこにあります。
-maaartinus

1
大規模なリファクタリングでは、ソース管理の更新を熟考して計画するのに少し時間をかける価値があります。多くの場合、最小限またはわずかな労力で、より多くの情報を保持できます。たとえば、ファイルを3つの部分に分割する場合、最初に3つの置換のそれぞれに元のコピーを保存します。その後、さらにコミットは3 ...修正する
UuDdLrLrSs

回答:


5

「変更された」または「修正されたバグ」タイプのコメント以上にコミット履歴を使用するには、問題追跡システムとリンクする必要があります。すべての変更、すべてのコミットには、それに関連するいくつかの問題があるため、変更内容、変更者、変更理由を把握する必要があります。

最新バージョンがすべてのソフトウェア要件を満たしている限り、実際にソースコードの履歴を保持する必要がありますか?

十分に複雑なソフトウェアでは、多くの理由ですべての要件が実装され、すべてのバグが修正されることはめったにないので、ここでのあなたの主張は楽観的だと思います。

プログラムのバージョン7.8を使用しているとします。しかし、1.6、2.2、2.8など、12種類のアクティブバージョンをフィールドでサポートしています。これらのそれぞれは、さまざまな理由で最新バージョンにアップグレードされないため、バグ修正ですべてをサポートしています。顧客が最新の7.8リリースでバグを見つけました。7.8で修正します。修正が必要な他のリリースの数をどのように知るのですか?ソース履歴と問題追跡がなければ、できません。


7

ソースコード履歴の価値は疑わしいようです。

エンジニアが数年前にソースコードに戻って、なぜそうなのかという答えを探してきました。バグを理解するには、時間の経過とともに物事が進化する方法が重要な場合もありますが、物事を文書化するときに通常考えられるものではありません(必ずしも文書化することもできません)。

また、ソースコードの履歴を保持する非常に正当な理由があるかもしれません。(ビルド/ SCMエンジニアとして)私がしなければならなかったほとんどのソースコードごみ箱ダイビングは、私の会社の法務部の要請に応じています。


1
個人的には、歴史を見ることはめったにありませんが、必要に応じて歴史を見ることは非常に貴重です。ですから、私は、そうすることが実際的であるとき、歴史を保存することを好みます。
UuDdLrLrSs

3

最新バージョンがすべてのソフトウェア要件を満たしている限り、実際にソースコードの履歴を保持する必要がありますか?

しかし、これとは別に、ソースコードのコミットの履歴を保持することに何か価値はありますか?

両方ともはい。何がいつ、誰によって、なぜ変更されたかを知ることは有用です。履歴を失うと、これを行う能力が影響を受けます。

ソースコードのコミット履歴は、チームメンバー間のコミュニケーションに何らかの役割を果たしますか?コミット履歴を廃止し、代わりに「ソースコード」+「ユニットテストコード」に依存して通信した場合はどうなりますか?

はい、そうです。「ソースコード」+「ユニットテストコード」のみのアプローチでは、誰/いつ/なぜなのかがわかりません。

コミット履歴の存在は、主要な設計/要件の変更やそれらの変更を推進した一連の思考など、プロジェクトに関する重要な情報の長期的な文書化に満足しますか?

あなたはそれがそうだと言うことができると思います。しかし、要件/設計の変更を完全に文書化する開発者はほとんどいません。そして確かに、最初の開発やその後の修正を推進した思考の流れを記録している人はほとんどいません。コミット履歴(特にコミットログメッセージ)を持ち、少なくとも問題/バグ追跡システムへのクロスリンクがあれば、そこから何かを提供できます。そして、それは何もないよりも、リリーススナップショットのセットよりも優れています。


1
+1また、通信のためにコードに依存するということは、履歴にある情報もコメントに存在し、DRYに違反することを意味します。
ラリーコールマン

1
@ラリー-本当。しかし、実際には、問題は多すぎる(または重複した)情報ではなく、記録された情報が少なすぎる可能性があります。
スティーブンC
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.