Git: What are the possible streams for two development environments?

Question

I’m setting up a development environment with Git in some of my projects, my initial idea for simple projects is:

• The master branch is blocked when someone needs to perform change is created a new branch (equal to master), change is made and the person opens a pull request to climb to master. So far okay.

The case I’m not sure about is when there are two development environments, for example: master (production) and develop (testing).

My idea was to develop being a copy of the master, when someone needs to make a change, a branch of the develop and when it’s finished it merges the branch into the develop.

At the time of merging from develop to master, if I’ve merged several branches to develop it, I can specify which branch I’ll go up to master?

Are there some more commonly used streams? Or best practices?

I don’t know if it’s clear but I can improve the explanation!

Updating:

I’ve reached a stream that I believe is viable:

Three environments built for two development environments

• Master
• Dev
• Testing

At first they are all the same, if someone needs to perform some Feature/Hotfix, it always creates a branch from the Dev, makes the change and merges with the branch Testing, if the tests are ok, the person merges his or her branch with the Dev, the branch Testing would always be there to test something and Dev would be all that is ready to go into production (master).

Answer 1

Using Git Flow as a branch organizer, I use it as follows:

• Branch master - It is the branch that contains code at the production level, that is, the most mature code in your application. All new code produced is eventually merged with the master branch at some point in development;

• Branch develop - It is the branch that contains code at the preparatory level for the next deploy. That is, when Features are terminated, they are merged with the develop branch, tested (together, in the case of more than one Feature), and only then do the updates of the develop branch go through one more process to then be merged with the master branch;

• Branches Feature/* - These are branches in which new resources are developed for the project in question. These branches are conventionally named starting with Feature/ (example: Feature/new-layout) and are created from the develop branch (as one resource may depend directly on another resource in some situations), and are ultimately merged with the develop branch;
• Branches Hotfix/* - These are branches in which critical bug fixes are performed that are found in the production environment, and are created from the master branch, and are merged directly with the master branch and the develop branch;
• Branches release/ * - These are branches with a higher level of trust than the develop branch, and are at the level of readiness to be merged with the master branch and the develop branch (in case there has been a bug fix on the/* release branch in question). Note that in these branches, bugs found during Features testing that go into production can be fixed more smoothly, before actually going into production. By convention, these branches have the name starting with release/ and ending with the number of the next version of the software (following the example of Hotfix, given above, would be something like release/2.32.0), usually following the rules of semantic versioning.