Structure of branchs and merge .NET MVC

1

I have the following branch 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'm having a problem when it comes to ratification and publication in production.

The flow is as follows:

  • New developments are made in the dev branch. Master merge for dev.
  • At the end of the task, commit (we use GIT) in dev and do the publish on the application server. In the case of approval dev merge with master.

At this point I have 2 problems.

  • If 2 dev's are developing in project MVC when generating publish for ratification a dev can overwrite the publish of the other disrupting ratification.
  • If the approval of Dev1 is approved and that of Dev2 is not like I am going to publish a production version without taking the changes to Dev2 since he has committed his task.

The same can happen for maintenance. Release branch because to begin the correction of a bug the master merge is done with release, commit in release and release merge with master.

Has anyone ever had a similar situation? How can I ensure parallel development by ensuring the correct versioning and avoiding sending non-homologated versions for production?

    
asked by anonymous 13.03.2015 / 21:28

1 answer

1
  • The correct one would be to publish only from the master, not from a development branch. In addition, every bug fix or development should have its branch separately, and not use a single branch for all development efforts.
  • Bugfixes should start with a branch in master ;
  • A branch should not be published in production . Master should receive the branch and the publication must be done by master . Approvals should be published only in development instances;
  • New features start with a branch in master (eg a Sprint in Scrum deserves a branch just for him). Every new development item (for example, a Scrum backlog item) must also have its separate branch ;
  • Each backlog item should enter as merge on top of the branch parent, and this branch parent, when development ends, should be reintegrated to master
  • Merges in master in branches should be avoided . Bidirectional Merges do not work very well in any version control whatsoever.

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

    
13.03.2015 / 22:42