Building the logic of the GIT system

Question

git

We have 2 people in the team who work on a fairly large system.
here I sketched a list of commands for setting up a GIT system.

The idea is as follows:
1. Each developer sets up a local copy of the site for himself.
2. Set up the central (remote) repository (with which we will synchronize)
3. In production, we also raise the repository (stable code will be poured here)

Global branch assignment:
1. master - this contains only stable and tested code, which can be release to production.
2. Development is carried out in branches with the names dev<version number>, for example, dev0.8, dev0.11, versions - a set of tasks that is combined into a version. When the goal is achieved, the version is tested, merged with the master and laid out for production.

I simulated it all on my local computer and it worked great. Only now my boss is not a person of principle, and for reasons that are not clear to me, categorically refuses to raise a local copy of the site.
If it is an option for him to make a separate remote site with a copy of the site and raise GIT there according to the principle the same as if it were a local copy of the site.

And this is where things start to get weird for me. In order for it to work with the code, the configured repository will need to be cloned, and then somehow work with the branches. How can this be properly organized?

PS Another question: the remote repository with which the developers will be synchronized must be bare or not?

Answer 1

You invent Git Flow .
Article on Habré: habrahabr.ru/post/147260/