Shulou(Shulou.com)06/02 Report--

This article mainly shows you the "composer download content need to be submitted to git", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "composer download content need to be submitted to git" this article.

Specific questions:

I would like to ask all of you who use Composer, will you submit the content to Git after downloading the file through Composer?

When I read the Should I Commit the dependencies in my vendor directory article on the official Faq, there is a suggestion that it should not be submitted to Git, so how should we deal with the problem of re-composer install when switching branches? If you submit vendor to the version library, what should you do with the .git folder that comes with the package?

* fixed that composer update should be composer install

Solution:

In fact, no matter whether it is branch development or deployment to a production environment, no matter how you write the wildcard rules for version numbers in composer.json, what we are most concerned about is the most fundamental content: what is the specific version number of all the dependent libraries we used at the time of development?

This content is supported by the composer.lock file. By maintaining the lock file, composer itself records the specific versions of all dependent libraries in the project after any changes have been made to the dependent libraries. Please read the documentation about this file (https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file).

You should always submit the composer.lock file to the version library, and after switching branches or deployments, use composer install to install the specific dependent version specified in the lock file.

In this sense, it is right whether you submit the vendor directory to the main version library. Whether to submit or not is a trade-off:

If you submit:

Advantages: the convenience of "pull and use".

Disadvantage: repetitive information. Because you developed the specific version at that time, the lock file has been recorded. This means that the vendor folder says the same thing.

Disadvantage: introduce the risk of inconsistency. Because although Composer guarantees that the lock file is consistent with the vendor directory, submitting it to the git version library is a human activity after all. You can't guarantee that you won't leave one of the two behind.

If it is not submitted, the advantages and disadvantages will be reversed. No more repetition.

My idea is: I suggest you stick to the idea that correctness is better than ease of use. My advice is not to commit the vendor, but just to use the lock file to maintain the version of the dependent library at the time of development.

If you submit, be sure to follow the following two guidelines:

(1) make sure that the submissions of vendor and composer.lock are synchronized. If one is mentioned, the other must be mentioned.

Any developer, if only one of them is handed over to commit at any one time, must be held accountable.

The reason for this is: although we submit vendor to guarantee that the pull will be available immediately, git has a partial checkout function-for a Composer project, I have the right to follow the convention of the Composer project, not to check out the vendor directory, but to pull down the actual code and then have a composer install at hand. You can't say I'm wrong.

(if anyone says this is wrong, I support your minute-by-minute sf and Zhihu exposure of your unscrupulous company and technical director.)

(2) be sure to follow Composer's recommendation to submit the vendor folder (https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md), ignore all .git directories of the sublibrary, and only submit the practice code in vendor.

Believe me, the actual code in vendor and the management files of the git library itself under vendor/**/.git are definitely the relationship between the water part of the iceberg and the underwater part. If you don't ignore it, you'll die. It's no exaggeration.

It must also be pointed out that when branch development, even if you do not synchronize vendor through the version library, but only synchronize composer.lock, it will not cause a waste of time.

When the two branches switch, it is nothing more than two sets of specific versions. Composer itself is cached for all downloaded libraries. The composer install after each pull branch is bound to hit all the cache without repeatedly consuming the download time.

The above is all the content of the article "should the content downloaded by composer be submitted to git?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.