workflow

Master => Feature => Master; master=> Feature => Master

Here is a brief introduction:

Master =>feature=>develop=>pre-master=>master

Scenario: This iteration of the project includes requirements A and B, and after evaluation, the completion of the development test is risk-free before the launch time. After the completion of development, the version (A and B functions) will be launched according to the deployment time of the iteration.

Operation process:

  • Separate Develop from Master, and then separate Develop from feature_newPage1 and feature_newPage2
  • Feature_newPage1 has modified the Common method to incorporate it into Develop, telling the feature_newPage2 people to pull Develop
  • After the development is complete and the test passes, it is merged into Develop and tested by testers
  • If there are bugs, fix them directly on Develop and then deploy the tests
  • If there are any bugs, go back to Develop and make changes
  • Finally, the pre-master test has no problem, merge to master

Advantages:

  • For feature1 and Feature2, which have a public component, the process is clear, and feature1 and feature2 developers can communicate with each other to quickly synchronize the common code

Disadvantages:

  • You cannot publish a version by module

Conclusion: when an iterative cycle of development needs, the public portion of the need to modify more, and at low risk of development (development) on time, you can use this process, the develop branch here is actually more like a version of the meaning, called sprint1, 2, 3… Branching would be more appropriate, with the version dimension ultimately merging with the master rather than the module dimension

Master =>feature=>develop=>pre-master, then feature=>master

Scenario: I received two requirements A and B. After the development is completed, the product manager will inform me that the production version will be updated next time. Only function A will be updated next time, and function B will be updated next time

Operation process:

  • According to the requirements, feature_newPage1 and feature_newPage2 are developed separately from the master
  • After the development is complete and the test passes, it is merged into Develop and tested by testers
  • If there are bugs, switch back to feature, make changes, and repeat the previous step (merge to Develop).
  • The Develop test worked fine, merge it into the pre-master test again
  • Finally, the feature is merged into the master to complete the development

Develop, pre-master, and Master branches do not communicate with each other in this process, so we need to synchronize the develop, pre-master, and Master branches every once in a while. Some conflicts may occur, and this needs to be handled manually

Advantages:

  • Versions can be updated based on functional modules

Disadvantages:

  • Periodically synchronize develop, pre-master, and Master
  • If feature2 has a feature that relies on feature1, for example, or if both feature1 and Feature2 use the Common1 method, feature1 has made significant changes to Common1! In this case, you might need to separate the common1 modification work out of a feature_common1 branch and develop this feature first, which is a bit of a hassle

Conclusion: This git development process can be adopted when developing multiple relatively independent functions, some of which are at risk and may not be available at the same time

The last

In fact, I have not studied git workflow in depth, but only listed two methods used in the work. Welcome to discuss and point out any suggestions and shortcomings!