Branchs and merge structure . NET MVC

Asked

Viewed 141 times

1

I have the following branchwork structure for ASP NET MVC projects

  • Master - production version
  • DEV - Development
  • Release - Bug maintenance

This structure was already defined when I arrived at the project and I have a problem when the time of approval and publication in production.

The flow is as follows:

  • New developments are made in the dev branch. Merge from master to dev.
  • Upon completion of the task, commit (we use GIT) in dev and Publish on the homologation application server. In case of approval merge dev with master.

At this point I have 2 problems.

  • If 2 dev’s are developing in the MVC project when generating Publish for homologation one dev can overwrite the other’s Publish by hindering homologation.
  • If Dev1’s approval is approved and Dev2’s not as I will publish a production version without taking the Dev2 changes since he committed his task.

The same can occur for maintenance. Release branch because to start fixing a bug is done the master merge with release, release commit and release merge with master.

Has anyone ever been in a similar situation? How can I ensure parallel development by ensuring correct versioning and avoiding sending unapproved versions to production?

asp.net-mvc git versioning

1 answer

1


  • The correct thing would be to publish only from master, not from a development branch. Also, each bug fix or development should have its branch separate, and not use a single branch for all development efforts.
  • Bug fixes should start with a branch started in master;
  • A branch shall not be published in production. Master must receive the branch and the publication must be done by master. Branches type-approval shall be published only in development bodies;
  • New features start with a branch in master (for example, a Sprint in Scrum deserves a branch just for it). Every new development item (for example, an item in a backlog Scrum) must also have his branch separately;
  • Each item of backlog must enter as merge on top of the branch father, and this branch father, when development ends, should be reintegrated into the master
  • Merges of master in branches developmental should be avoided. Merges bidirectional do not work very well on any version control that is.

In this extensive handbook of good practice there are these arguments that I used best developed.

  • In the case of item 3. Master receives my branch (backlog item for example). After the publication the user has not approved, however, other people have also sent their changes to master and need to publish in Prod. How will I do not send the unapproved changes since they are in master as well?

  • This here cannot: "The user has not approved and other people have sent to master". It is clearly a procedural flaw. If the user needs to approve, you should publish the branch that has received all the other branch-child functionality, and not try to put the bug fixes all on the same branch, otherwise it gets messy. I edited the answer to make it clear.

Browser other questions tagged asp.net-mvc git versioning

You are not signed in. Login or sign up in order to post.