"Es hängt davon ab, ob." Für normales Entwicklungs-Tracking, nein. Für Cloud- und DevOps-Bereitstellungen ist dies jedoch häufig praktisch oder sogar erforderlich.
Meistens ist
@ptyx korrekt . In der Tat könnte sein "Nein" etwas nachdrücklicher ausgedrückt werden. So etwas wie "Nein, nein! OMG NEIN! "
Warum nicht minimierte oder komprimierte Assets in einem Quellcodeverwaltungssystem wie Git speichern?
Sie können durch Ihren Build-Prozess im laufenden Betrieb aus dem Quellcode fast trivial neu generiert werden. Beim Speichern komprimierter Assets wird im Grunde derselbe logische Inhalt zweimal gespeichert. Es verstößt gegen das Prinzip "Wiederhole dich nicht" (auch bekannt als DRY ).
Ein weniger philosophischer, aber praktischerer Grund ist, dass minimierte / optimierte Assets beim Speichern in Git eine sehr schlechte Komprimierbarkeit aufweisen. Versionsverwaltungssysteme erkennen die Änderungen ("Deltas") zwischen verschiedenen Versionen jeder gespeicherten Datei. Dazu "unterscheiden" sie die neueste Datei von der vorherigen Version und verwenden diese Deltas, um zu vermeiden, dass eine vollständige Kopie jeder Version der Datei gespeichert wird. Die im Schritt Minimieren / Optimieren vorgenommenen Transformationen entfernen jedoch häufig die Ähnlichkeiten und Wegpunkte, die die Diff / Delta-Algorithmen verwenden. Das trivialste Beispiel ist das Entfernen von Zeilenumbrüchen und anderen Leerzeichen. Der resultierende Vermögenswert ist oft nur eine lange Schlange. Viele Teile des Web-Build-Prozesses - Tools wie Babel , UglifyJS , Browserify ,Less und Sass / SCSS - transformieren Assets aggressiv. Ihre Ausgabe ist störend; Kleine Eingangsänderungen können zu großen Änderungen der Ausgabe führen. Infolgedessen glaubt der Diff-Algorithmus oft, dass er jedes Mal fast eine völlig andere Datei sieht. Ihre Repositories wachsen dadurch schneller. Ihre Festplatten sind möglicherweise groß genug und Ihre Netzwerke schnell genug, was kein großes Problem darstellt, insbesondere wenn die zweimalige Speicherung der minimierten / optimierten Assets einen Wert hat. Basierend auf Punkt 1 sind die zusätzlichen Kopien möglicherweise nur zu 100% sinnlos aufblähen.
Es gibt jedoch eine große Ausnahme: DevOps / Cloud-Bereitstellungen. Eine Reihe von Cloud-Anbietern und DevOps-Teams verwenden Git und ähnliches nicht nur, um Entwicklungsupdates zu verfolgen, sondern auch, um ihre Anwendungen und Assets aktiv auf Test- und Produktionsservern bereitzustellen. In dieser Rolle kann Git effizient feststellen, "welche Dateien geändert wurden?" ist ebenso wichtig wie seine detailliertere Fähigkeit zu bestimmen, "was sich in jeder Datei geändert hat?" Wenn Git eine fast vollständige Dateikopie für minimierte / optimierte Assets erstellen muss, dauert dies etwas länger als sonst, aber keine große Sache, da es immer noch hervorragende Arbeit leistet, um eine Kopie von "jeder Datei im Projekt" auf jeder zu vermeiden Bereitstellungszyklus.
Wenn Sie Git als Deployment-Engine verwenden, kann das Speichern minimierter / optimierter Assets in Git von "Nein!" zu wünschenswert. In der Tat kann dies erforderlich sein, beispielsweise wenn Sie auf den Servern / Diensten, auf denen Sie bereitstellen, keine soliden Build- / Nachbearbeitungsmöglichkeiten haben. (Das Segmentieren von Entwicklungs- und Bereitstellungsressourcen in diesem Fall ist eine separate Dose von Würmern. Derzeit reicht es aus zu wissen, dass sie auf verschiedene Arten verwaltet werden können, einschließlich mit einem einzigen einheitlichen Repository, mehreren Zweigen, Unterrepositorys oder sogar mehreren überlappenden Repositorys. )
/dev/null.