Die folgende Tutorial-Kolumne vonComposerstellt Ihnen die Frage vor, ob der vom Composer heruntergeladene Inhalt an Git übermittelt werden muss. Ich hoffe, dass er Freunden, die ihn benötigen, hilfreich sein wird!
Spezifische Frage:
Ich möchte alle Schüler, die Composer verwenden, fragen: Werden sie den Inhalt der über Composer heruntergeladenen Dateien an Git übermitteln?
Ich habe den Artikel „Sollte ich die Abhängigkeiten in meinem Anbieterverzeichnis festschreiben“ in der offiziellen FAQ gesehen? Einige Leute haben vorgeschlagen, ihn nicht an Git zu senden. Wie soll ich also mit dem Problem der Neuinstallation von Composer beim Zweigwechsel umgehen? Wie soll mit dem .git-Ordner im Paket umgegangen werden, wenn der Anbieter an das Repository übermittelt wird?
*Korrektur Composer-Update sollte Composer-Installation sein
Lösung:
Egal, ob es sich um eine Zweigentwicklung oder eine Bereitstellung in einer Produktionsumgebung handelt, egal, wie Sie die Platzhalterregel für die Versionsnummer in Composer.json schreiben , wir machen uns darüber am meisten Sorgen. Der grundlegendste Inhalt ist immer: Wie lauten die spezifischen Versionsnummern aller abhängigen Bibliotheken, die wir während der Entwicklung verwendet haben?
Und dieser Inhalt wird von der Datei „composer.lock“ unterstützt. Durch die Verwaltung von Sperrdateien zeichnet Composer selbst die spezifischen Versionen aller abhängigen Bibliotheken im Projekt auf, nachdem Änderungen an den abhängigen Bibliotheken vorgenommen wurden. Bitte lesen Sie die Dokumentation zu dieser Datei (https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file).
Sie sollten die Datei „composer.lock“ immer an das Repository senden und nach dem Wechseln der Zweige oder der Bereitstellung die Composer-Installation verwenden, um die in der Sperrdatei angegebene spezifische Abhängigkeitsversion zu installieren.
In diesem Sinne ist es richtig, ob Sie das Anbieterverzeichnis an das Haupt-Repository übermitteln. Es ist ein Kompromiss, ob Sie einreichen oder nicht:
Wenn Sie einreichen:
Vorteile: „Ziehen und verwenden“-Komfort.
Nachteile: Doppelte Informationen. Aufgrund der spezifischen Version, die Sie zu diesem Zeitpunkt entwickelt haben, wurde die Sperrdatei aufgezeichnet. Mit anderen Worten: Der Herstellerordner drückt dasselbe aus.
Nachteil: Gefahr der Einführung von Inkonsistenzen. Denn obwohl Composer sicherstellt, dass die Sperrdatei mit dem Herstellerverzeichnis übereinstimmt, ist die Übermittlung an das Git-Repository letztlich ein manueller Vorgang. Sie können nicht garantieren, dass Sie nicht hinter einen der beiden zurückfallen.
Wenn Sie nicht einreichen, kehren sich die Vor- und Nachteile um. Das soll nicht noch einmal wiederholt werden.
Meine Gedanken sind: Ich schlage vor, Sie bleiben bei der Idee „Korrektheit geht vor Benutzerfreundlichkeit“. Mein Vorschlag ist, es nicht an den Anbieter zu übermitteln, sondern einfach die Sperrdatei zu verwenden, um die Version der abhängigen Bibliothek zum Zeitpunkt der Entwicklung beizubehalten.
Wenn Sie einreichen, beachten Sie bitte unbedingt die folgenden zwei Richtlinien:
(1) Stellen Sie sicher, dass die Übermittlung der beiden Dateien „vendor“ und „composer.lock“ synchronisiert ist. Wenn eines erwähnt wird, muss auch das andere erwähnt werden.
Jede Entwicklung muss zur Rechenschaft gezogen werden, wenn zu irgendeinem Zeitpunkt nur einer der Commits eingereicht wird.
Der Grund dafür ist: Obwohl wir uns dem Anbieter unterwerfen, um sicherzustellen, dass es sofort nach dem Ziehen verfügbar ist, verfügt Git über eine teilweise Checkout-Funktion – für ein Composer-Projekt habe ich das Recht, der Konvention des Composer-Projekts zu folgen und nicht Sehen Sie sich das Herstellerverzeichnis an, laden Sie aber den eigentlichen Code herunter und führen Sie dann eine Composer-Installation durch.
(Wenn jemand sagt, dass dies falsch ist, unterstütze ich Sie dabei, Ihr skrupelloses Unternehmen und Ihren technischen Direktor jede Minute auf SF und Zhihu zu entlarven)
(2) Befolgen Sie unbedingt die Vorschläge des Composer zur Übermittlung des Anbieterordners (https:// getcomposer. org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md), ignorieren Sie alle .git-Verzeichnisse der Unterbibliothek und übermitteln Sie nur den tatsächlichen Code beim Anbieter.
Glauben Sie mir, der eigentliche Code im Vendor und die Verwaltungsdateien der Git-Bibliothek selbst unter Vendor/**/.git hängen definitiv mit dem Überwasserteil und dem Unterwasserteil des Eisbergs zusammen. Wenn man es nicht ignoriert, werden Menschen sterben. Das ist keine Übertreibung.
Es muss auch darauf hingewiesen werden, dass während der Zweigentwicklung keine Zeitverschwendung entsteht, auch wenn Sie den Anbieter nicht über das Repository synchronisieren, sondern nur Composer.lock synchronisieren.
Beim Wechsel zwischen zwei Zweigen handelt es sich um nichts anderes, als zwischen zwei bestimmten Versionen hin und her zu wechseln. Composer selbst speichert alle heruntergeladenen Bibliotheken zwischen. Die Composer-Installation nach jedem Branch-Pull wird auf jeden Fall alle Caches erreichen, ohne wiederholt Download-Zeit zu beanspruchen.
Das obige ist der detaillierte Inhalt vonMuss der vom Komponisten heruntergeladene Inhalt an Git übermittelt werden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
