15 Laravel Tips to Work in a Team

How to remove constraints using migration when data is already present.

awesome, love it, thank you LD

I know it's an old video, but I faced aproblem recently: dev1 working on feature_1, dev2 working on feature_2 at the same time. Dev1 creates some migrations and execute it on his machine. Dev2 do the same, but dev2's migrations are create before dev1's. So when both merge their work, and dev1 will run migration, to migrate dev2 work, nothing is migrated due to the date of creation of that migrations. Is there a way to solve this?

you are best

Thanks! I'll see it later.

I think I disagree with editing migrations. In a project that isn't in production, you should always edit existing migrations. Most db changes happen in development and if you keep adding new migrations you could end up with a thousand migrations by the time the project is ready to launch.
Everyone should be running migrate:fresh in development constantly. So editing migrations shouldn't be a problem.
Then once the project is in production, switch to adding migrations for db changes. That is what migrations are primarily for, safely updating production environments.

Don't want to be over on easy thing, but when working with other people, don't be lazy on naming more helpful commit, add a little description if the commit not obvious. Take some time to add comments for the commit if using cloud repository

All good

This video will definitely help me
Thank you very much.

Great tips. Thanks.

for admin users I prefer making an interactive command, this way I'm sure the password is never committed and I won't forget to change it

Thank you so much

Very helpful tips.. thanks 😊
Just wanted to know, how to create or maintain the UML diagrams for the big project and documentation of the flow of code in laravel...

Another great video! It was very difficult for me to work in team for the first time. If I had found video like this one, I think everything would be better ...
Only one thing I prefer in another way:
I use guarded instead of fillable and throw 'id' as first element of array (to prevent overwrite). In that case, if someone add new column in table, the column should be not declared in fillable. Yes, is not so readable, but is more easy and (still) secure and I provide a case of my experience - one of my teammates add new column in existing table with dozen of relations (the most of relations was not cascade) and for some reason he did not delcared it in fillable. I pull and try to create new record in db and Laravel throw me error - this column is not fillable. So, from this moment, I just add (for most projects) trait with protected $guarded = ['id'] and use this trait in base class.
Thanks for the great video, Mr. Korop!

RE: Using Seeders

Use migrations for creating REQUIRED data such as foreign key tables for enums, or adding new data to existing tables (static data that is always required, status table for example).
Seeders are good for adding demo / scaffolding data, however are not easily reversed in a production environment

Thank you for useful tips

In the part form request is good practice make one request for model ? for example make:request UserRequest and apply switch case with methods (get, post, put, patch, deleite, whatever method).