Organization of work with repositories

goals:
- organization of continuous implementation of the new project functionality
- related bug fixes in the project support process
- improving the quality of the project as a whole
- atomicity of development of individual parts of the project (modules / functions)

To achieve the goals described above, it is necessary to organize the following branch structure:
release
hotfixes (optional)
testing
fixes (optional)
default
developers branches (code name)

1. Release
This branch contains the current working copy of the project, from which the project is rolled out on the production server.

2. Hotfixes
It’s no secret that after rolling out a project to the production server, unexpected bugs may appear,
most often these are minor flaws, if the bug is indeed minor, then editing is allowed directly
in the Release branch, if the edit is not trivial, then you should do this:
a create a branch from the Release branch (hotfixes_ should be present in the branch name as a prefix, for example: hotfixes_calls)
b fix bug.
c switch to the release branch
d get to the Release branch, all edits from the branch with a fixed bug.
e test (if possible)
f update the production server from the Release branch
g increase the value of the version of the tag by 1 (for example: it was 1.0.0, it became 1.0.1)
')
3 Testing
This branch contains new features that should get into the next version of the project.
Under this branch should be a separate environment, as close as possible to the fighting,
The code that is in this thread is being actively tested.
when any bugs are detected, in the code of this branch, we make changes, until the bugs are completely eliminated.

At the end of testing, and fixing bugs, do the following:
a switch to the release branch
b get to the Release branch all edits from the Testing branch
c test (if possible)
d update production server from the Release branch

4 Fixes
the work process is similar to the process described in section 2. (an example of use is described in the “work process” section)

5 Default
This branch contains project features that are ready to enter the testing stage. A branch exists solely to
so that developers can test the functionality as a whole, on the project (interaction of modules of several developers)

6 Developers branches
In fact, this is not a branch, it is a common name for all branches that are new functionality.

Work process:
when a set of new features is ready (and at least minimally tested by each programmer of its functionality),
and the manager gave the nod to roll out a new functional, then the merging of the feature into the default branch occurs
(the programmer looks at how his functionality works with other modules), if all is well,
then we merge features from the default branch into the testing branch. From this point on, the appearance of new features in the current release is not desirable.
code that is in the testing branch is subjected to testing, bug fixes
(fixing bugs occurs in the same manner as in the case of hotfixes, only to fix significant bugs
branches are nicknamed simply fixes_, for example, fixes_calls)
after the main QA, confirmed the readiness of the code to work on the production server, merge the changes with testing in release.
The current version that is in production is tagged. (for example: it was 1.0.640 became 1.1.0)