Git: what are the possible flows for two development environments?

Question

Git: what are the possible flows for two development environments?

Navigation

#1 by (2 votes)
#2 by (-3 votes)

0

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 make a change, a new branch is created (same as the master), the change is made and the person opens a pull request to move to the master. So far, okay.

The case that I am having doubts is when there are two development environments, for example: master and develop.

My idea was to develop a copy of the master, when someone needs to make a change, a develop branch is created and when it is finished from a branch merge in develop .

At the time of merge from develop to master, if I have merge multiple branches to develop, can I specify which branch I'm going to upload to master?

Are there any commonly used streams? Or good practices?

I do not know if it's clear but I can improve the explanation!

Updating:

I came to a stream that I believe is workable:

Three environments built for two development environments

-Master-

-Dev -

-Tests -

At first all are the same, if someone needs to perform some feature / hotfix, they always create a branch from Dev , make the change, and merge with the / strong>, if the tests are ok, the person merge your branch with Dev , the Test branch would always test something and Dev would be all that is ready to go to (master ) production.

versionamento git git-flow

asked by anonymous 28.09.2018 / 19:41

2 answers

Error with controller in codeigniter with the name system.php Query MySQL in PHP only works locally

score 2 · Answer 1

Using Git Flow as branch organizer, I use the following form:

Branch master - This is the branch that contains production-level code, which is the most mature code in your application. All new code produced is eventually joined with the branch master at some point in development;
Branch develop - This is the branch that contains code at the preparatory level for the next deploy. That is, when features are finished, they are joined with the branch develop, tested (together in the case of more than one feature), and only then the updates of the branch develop go through another process to be joined with the branch master;
Branches feature / * - Branches in which new features are developed for the project in question. These branches are conventionally named starting with feature / (example: feature / new-layout) and are created from the branch develop (since a resource can depend directly on another resource in some situations), and, in the end, are joined with a branch develop;
Branches hotfix / * - Branches in which critical bug fixes are found in the production environment, and are therefore created from the master branch, and are joined directly with the master branch and with a branch develop;
Branches release / * - Branches with a higher level of trust than the branch develop, and are at the preparation level to be joined with the branch master and branch develop (in case you have some bug fix in the branch release / * in question). Note that, in these branches, bugs encountered during the testing of the features that go into production can be corrected more quietly before they actually go into production. By convention, these branches have the name beginning with release / and ending with the next version number of the software (following the example of the hotfix, given above, would be something like release / 2.32.0), usually following the rules of semantic versioning.

score -3 · Answer 2

You can create a structure as follows:

Branchs:

master
estage
dev
atv-01
atv-02
atv-03
[...]

The master branch will be the backup of your application, it will be the last stable version. Home A stage branch will be your current production version. Home The branch dev will be your next delivery. Home The branch atv-01, atv-02, etc. will be your backlog activities, your tasks, each one can be from a different person.

When the activities are ready you merge into the dev branch that will be tested in the approval environment, after the test you merge with the stage branch that will be put into production.