Le contenu téléchargé par composer doit-il être soumis à git ?

La colonne tutorielle suivante de composer vous présentera la question de savoir si le contenu téléchargé par composer doit être soumis à git. J'espère qu'il sera utile aux amis qui. j'en ai besoin !

Questions spécifiques :

J'aimerais demander à tous les étudiants qui utilisent Composer : allez-vous soumettre le contenu des fichiers téléchargés via Composer à Git ?
J'ai vu l'article Dois-je valider les dépendances dans mon répertoire de fournisseurs sur la FAQ officielle. Certaines personnes ont suggéré de ne pas le soumettre à Git. Alors, comment dois-je gérer le problème de l'installation du re-composer lors du changement de branche ? Si le fournisseur est soumis au référentiel, comment le dossier .git du package doit-il être géré ?

*La mise à jour de la correction composer doit être composer install

Solution :

En fait, qu'il s'agisse de développement de branche ou de déploiement en production environnement , quelle que soit la manière dont vous écrivez les règles génériques pour le numéro de version dans composer.json, ce qui nous préoccupe le plus est toujours le contenu le plus fondamental : au moment du développement, quel est le numéro de version spécifique de toutes les bibliothèques dépendantes que nous utilisé?

Et ce contenu est pris en charge par le fichier composer.lock. En conservant les fichiers de verrouillage, composer lui-même enregistre les versions spécifiques de toutes les bibliothèques dépendantes du projet après que des modifications aient été apportées aux bibliothèques dépendantes. Veuillez lire la documentation sur ce fichier (https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file).

Vous devez toujours soumettre le fichier composer.lock au référentiel, et après avoir changé de branche ou déployé, utiliser composer install pour installer la version de dépendance spécifique spécifiée dans le fichier de verrouillage.

En ce sens, il est correct que vous soumettiez le répertoire des fournisseurs au référentiel principal. C'est un choix de compromis de soumettre ou non :

Si soumis :

Avantages : commodité « Tirer et utiliser ».

Inconvénients : Informations en double. En raison de la version spécifique que vous avez développée à l'époque, le fichier de verrouillage a été enregistré. En d’autres termes, le dossier fournisseur exprime la même chose.

Inconvénient : Risque d’introduire une incohérence. Car même si Composer garantit que le fichier de verrouillage est cohérent avec le répertoire du fournisseur, le soumettre au référentiel git est après tout un acte manuel. Vous ne pouvez pas garantir que vous ne prendrez pas de retard sur l’un des deux.

Si vous ne soumettez pas, les avantages et les inconvénients seront inversés. A ne plus répéter.

Mes pensées sont les suivantes : je vous suggère de vous en tenir à l'idée de "l'exactitude plutôt que la facilité d'utilisation". Ma suggestion n'est pas de soumettre au fournisseur, mais simplement d'utiliser le fichier de verrouillage pour conserver la version de la bibliothèque dépendante au moment du développement.

Si vous soumettez, assurez-vous de suivre les deux directives suivantes :

(1) Assurez-vous que la soumission des deux fichiers supplier et composer.lock est synchronisée. Si l’un est mentionné, l’autre doit être mentionné.
Tout développement, si un seul des commits est soumis, doit être tenu pour responsable.
La raison en est la suivante : bien que nous le soumettions au fournisseur pour nous assurer qu'il est disponible immédiatement après l'avoir extrait, git a une fonction de récupération partielle - pour un projet Composer, j'ai le droit de suivre la convention du Composer projet et ne consultez pas le répertoire du fournisseur, mais extrayez le code réel, puis effectuez une installation du compositeur. Vous ne pouvez pas dire que je me trompe.
(Si quelqu'un dit que c'est faux, je vous aide à dénoncer votre entreprise et votre directeur technique sans scrupules sur SF et Zhihu chaque minute)

(2) Assurez-vous de suivre les instructions du compositeur pour soumettre le dossier du fournisseur Suggestion (https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md), ignorez tous les répertoires .git de la sous-bibliothèque et soumettez uniquement ceux de Code de bonnes pratiques du fournisseur.
Croyez-moi, le code lui-même dans le fournisseur et les fichiers de gestion de la bibliothèque git elle-même sous supplier/**/.git sont définitivement liés à la partie au-dessus de l'eau et à la partie sous-marine de l'iceberg. Si vous ne l’ignorez pas, des gens mourront. Ce n’est pas une exagération.

Il faut également souligner que lors du développement de la branche, même si vous ne synchronisez pas le fournisseur via le référentiel, mais synchronisez uniquement composer.lock, cela ne provoquera pas de perte de temps.

Lors du basculement entre deux branches, il ne s'agit rien de plus que de basculer entre deux versions spécifiques. Composer lui-même met en cache toutes les bibliothèques téléchargées. L'installation du compositeur après chaque extraction de branche atteindra définitivement tous les caches, sans consommer de temps de téléchargement répété.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!