Die Verwendung des vom Versionskontrollsystem verwalteten Festschreibungsverlaufs kostet fast nichts. Während eines größeren Projekts zur Umgestaltung (oder Reorganisation / Bereinigung) werden jedoch Funktionen und Klassen und sogar Namespaces verschoben. Manchmal werden mehrere Dateien zusammengeführt und andere Dateien werden aufgeteilt. Diese Änderungen führen häufig zum Verlust des ursprünglichen Festschreibungsverlaufs einiger Dateien.
Meiner persönlichen Meinung nach ist die Aufrechterhaltung der Organisation des Projekts wichtiger als die Aufrechterhaltung des Quellcodeverlaufs. Durch eine gute Projektorganisation können mit angemessenem Aufwand kontinuierlich neue Funktionen hinzugefügt werden, während der Wert des Quellcodeverlaufs zweifelhaft erscheint.
Darüber hinaus werden durch die Verwendung von Unit-Tests Regressionsprobleme schnell identifiziert. Müssen wir tatsächlich den Verlauf des Quellcodes beibehalten, solange die neueste Version alle Softwareanforderungen erfüllt?
Ich verstehe, dass jeder ausgelieferte Quellcode erhalten bleiben muss, da die Kunden unterstützt werden müssen, ohne dass sie ein größeres Versions-Upgrade durchführen müssen. Aber abgesehen davon, gibt es irgendeinen Wert, den Verlauf von Quellcode-Commits beizubehalten?
Spielt der Quellcode-Commit-Verlauf eine Rolle bei der Kommunikation zwischen Teammitgliedern? Was ist, wenn wir den Commit-Verlauf abschaffen, uns aber stattdessen auf "Quellcode" + "Unit-Test-Code" für die Kommunikation verlassen?
Macht das Vorhandensein eines Commit-Verlaufs die langfristige Dokumentation wichtiger Informationen über das Projekt, wie z. B. die wichtigsten Design- / Anforderungsänderungen und die Gedankenströme, die diese Änderungen ausgelöst haben, selbstgefällig?
quelle
These changes often lead to the loss of the original commit history of a few files.Schauen Sie sich zB "git tad" an - nichts geht verloren. Manchmal ist es etwas schwieriger zu finden, aber es ist immer da.Antworten:
Um den Commit-Verlauf für mehr als Kommentare vom Typ "vorgenommene Änderungen" oder "Fehler behoben" zu verwenden, sollte er mit Ihrem Problemverfolgungssystem verknüpft sein. Mit jeder Änderung, jedem Commit sollte ein Problem verbunden sein, damit Sie wissen, was sich von wem und warum geändert hat.
Ausreichend komplexe Software hat selten alle Anforderungen implementiert und alle Fehler aus einer Vielzahl von Gründen behoben. Ich denke, Ihre Behauptung hier ist beispielsweise optimistisch.
Angenommen, Sie befinden sich in Version 7.8 Ihres Programms. Sie unterstützen jedoch vor Ort 12 verschiedene aktive Versionen wie 1.6, 2.2, 2.8 usw. Jedes dieser Elemente wird aus verschiedenen Gründen nicht auf die neueste Version aktualisiert. Daher unterstützen Sie alle mit Fehlerkorrekturen. Ein Kunde findet einen Fehler in Ihrer neuesten Version 7.8. Sie beheben es in 7.8. Woher wissen Sie, wie viele der anderen Releases repariert werden müssen? Ohne Quellverlauf und Problemverfolgung ist dies nicht der Fall.
quelle
Ich habe Ingenieure mehrere Jahre lang im Quellcode nach Antworten suchen lassen, warum etwas so ist, wie es ist. Manchmal ist die Art und Weise, wie sich die Dinge im Laufe der Zeit entwickelt haben, wichtig, um einen Fehler zu verstehen, aber es ist nicht etwas, woran man normalerweise denkt, wenn man Dinge dokumentiert (und auch nicht unbedingt dokumentierbar).
Es kann auch sehr gute rechtliche Gründe geben, den Quellcode-Verlauf beizubehalten. Die meisten Quellcode-Müllcontainer-Tauchgänge, die ich (als Build- / SCM-Ingenieur) durchführen musste, wurden auf Anfrage der Rechtsabteilung meines Unternehmens durchgeführt.
quelle
Ja zu beiden. Es kann nützlich sein zu wissen, wann, von wem und warum etwas geändert wurde. Wenn Sie Ihre Historie verlieren, wird Ihre Fähigkeit dazu beeinträchtigt.
Ja tut es. Der Ansatz "Quellcode" + "Unit-Test-Code" sagt Ihnen nicht, wer / wann / warum.
Ich nehme an, man könnte sagen, dass es so ist. Nur wenige Entwickler dokumentieren die Änderungen der Anforderungen / des Designs jemals gründlich. Und sicherlich zeichnet fast niemand den Gedankenstrom auf, der die anfängliche Entwicklung oder die nachfolgenden Modifikationen vorangetrieben hat. Wenn Sie den Festschreibungsverlauf (und insbesondere die Festschreibungsprotokollnachrichten) und Querverbindungen zum Problem- / Fehlerverfolgungssystem haben, haben Sie zumindest etwas zu bieten. Und das ist besser als nichts oder eine Reihe von Release-Schnappschüssen.
quelle