How to properly organize a working environment for a large project with GIT?

Question

git

Hello.
Probably every developer at some point in time began to wonder how to properly organize their work environment when developing a large project, especially when you are not working on a project alone.
So I have such a moment) I
am planning to develop a medium project (information portal), technologies and tools used: Laravel, GIT, Gulp, maybe React - I need to study it first)
And now I wonder how to organize and connect all this with
Git what I represent):
Branching model for Git: I liked this model https://habrahabr.ru/post/106912/ seems very convenient
The main domain is planned for example site.ru
Test site testsite.ru - so that the whole team can test the site / new features / fixed bugs
And then, after testing, upload everything to the main domain.
With files, everything is clear, but most of all I'm interested in how to work with MySQL with this approach.
After all, it turns out that the base is the same for site.ru
testsite.ru - uses the site.ru base?
And what kind of database do local versions of sites use?
Or clone databases from site.ru to testsite.ru and local site?
If the database changes its structure, create migrations and then apply migrations to site.ru?
And another situation: there will be a lot of images on the site (for a couple of gigs), it’s stupid to upload everything to the git ...
for testsite.ru, it’s also somehow stupid to duplicate all the images.
Same with the local version.
It seems to me the following solution:
use a subdomain like image.site.ru or a new domain like imagesite.ru
That's all)
These moments I still can't figure out how they should be organized.
I would like to hear how you solved similar problems for your similar projects.
I hope someone decides to read this long question))

Answer 1

- For images, you can use s3, but if you still want to store them on your own, then just throw them into the folder that is in gitignore. And 2GB for images is not much, but very little.
- The base should be cloned, not used the same one.
- Migrations were invented for this, so that it would be convenient to modify the base.
- There must be 3 sites: dev.site.ru, pre-prod.site.ru, site.ru. On the first development, on the second test of new features, well, production.

Answer 2

Firstly, use Bitbucket, everything is very flexible and convenient for teamwork, they even made a link with Trello now. which is just great. A team of up to 5 people is a freebie. Then you can clearly configure the rights of each developer to write. Pictures for several gigs are not a software part, of course it does not need to be stored in a git, only pictures swinging interface elements. There should be a clear instruction for new arrivals in order to work with the repository - everyone usually works in their own branch or in a feature branch, if they are given a specific task, each developer must pull updates from the central development branch into his branch at each start of work. When he tests everything at home, he will be able to send his ideas for verification to the main branch. No rights to anyone except the elder to write to the main branch! Otherwise it will be chaos. Periodically, everyone on the team will also make migrations in their branches. Well, there must be a team leader who will manage all this disgrace, resolve conflicts in the repository, divide and rule.

Answer 3

You can organize whatever you want.
I'll tell you how it is with us, a development team of 14 people. The rest are managers, testers, etc.
Bitbucket, Jira.
We use Kanban.
A task/bug/... is created with a number that is set automatically. An executor is appointed. For appointments, there is a project manager, etc. In the JetBrains product, the item - open task is selected. A branch with the task number is created automatically (let it be test389).
Next, you code or whatever you do there, pour it into a turnip on a remote test389 branch.
According to your code, a code review is carried out, if everything is normal, then it is merged into the master.
When merging with the master, tests are automatically launched.
Если все ок, выливают на дев сервер, там за дело берутся тестеры.
Когда тестеры все проверили и одобрили, изменения (обычно их пачка), выливаются на прод.
Вариантов много, но мы используем mongodb. Там уже более миллиона фотографий.
база должна быть одинаковая на всех видах сайта (тест, дев, прод...), для этого используются миграции.
Для фейковых данных можно использовать Faker.
P.S.
В гит вы храните только свой код, вендор там не нужен.