CODEWITHSUNDEEP
gitlaravel
Arthur Tarasov
Arthur Tarasov

Reputation: 3791

Should I use .gitignore for Laravel?

I am wondering if it is an acceptable practice NOT to use .gitignore entirely and commit everything there is, at least for small to medium projects. Laravel, as any framework I can imagine, has a lot of dependencies so they are set up to be ignored by git. This is what my default .gitignore file looks like:

/vendor
/node_modules
/public/storage
Homestead.yaml
Homestead.json
.env

I understand that vendor and node_modules contain the dependencies. Homestead files are local machine settings, and .env contains environment settings and differs between local and remote servers. I am not sure what storage has in it.

I ran into a problem when I pulled a lot of dependencies, which I haven't kept a good track of, and my node_modules and vendor directories exploded into 1 gb with 150,000 files. I quickly realized that it was a mistake and tried to roll back to a previous version. That, of course, failed because those two folders weren't tracked.

After spending a day rebuilding my project from scratch, I am now tempted to delete all .gitignore files from my Laravel project. Given that I only use git locally and don't push to live server, is it a good idea to commit everything? Does anyone else do that?

Upvotes: 5

Views: 2477

Answers (2)

Alfonz
Alfonz

Reputation: 1020

Dependencies

You generally should gitignore dependencies. (See this FAQ from Composer docs). If you wanted to rollback to a previous version, you can just remove the vendor / node_modules folders, and run composer install / npm install again to install the dependencies inside the composer.json / package.json of that specific commit.

.env file

For the .env file, aside from the fact that the settings differ between servers, it also contains private information such as database credentials, so you should gitignore that as well unless you're absolutely certain you won't be pushing it to some place that other people can see (e.g. a public GitHub repository).

storage folder

The storage folder is usually where things like uploaded files are saved and it depends on your application if you should ignore it or not.

Upvotes: 2

Chris
Chris

Reputation: 58182

Two part answer.

The explosion

You mentioned that your vendor/node_modules folders exploded in size. Even though you don't have them in version control - if you are using composer and npm correctly (by using the --save directive for npm), all modules should be listed in composer.json and package.json respectively. Meaning even if the installed libraries (in vendor + node_modules) weren't in version control, the package.json and composer.json should be - meaning you should be able to go back through time, and install the packages at that point in time using your composer/package jsons.

Should I...

Second part to this answer is should you include vendor/node_modules in version control? This is a fair question, and one often asked. I think ultimately it depends on your intention to deploy.

Do you have essentially unlimited space on your origin (github, bitbucket, etc) and you want your deployment to be a simple super git push to your production version? You can probably just commit everything, including vendor libraries. That way you have complete control of what is going up to your server.

Realistically, you might need to php artisan migrate when you push, so in turn, you might start to consider git hooks, and the process starts to become a bit more complex (but arguably better/scalable/robust). With those hooks in place, you could start to look at running composer install + npm install against the package.json and composer.json files (without the entire vendor libraries in git). If you go this avenue, you want to make sure your composer/package jsons are nice and locked down - no '3.x.x' version numbers - you want locked down versions that you know work and have been tested.

Upvotes: 2

Related Questions