Git-based workflow

This article is aimed at the pursuit of the ultimate, fast product response team. The following views and content are centered around this topic and are not involved in individual learning and team learning for the time being.

Talking about the work flow between, want to talk about our ordinary work encountered some confusion or phenomenon

In a team, there are a lot of events to solve. Some are product iterations, some bug modification, some may be the technical structure adjustment and so on. How to guarantee their independence? When should I cut branches? Can the merged branch be modified again? When does a branch need to be deleted? When does the life cycle of this branch be completed? Can the trunk modify the code? How many branches are merged into the trunk before a version is released? When will the version be stable? When do I need to mark?
............

There may be more questions during the period. But the sum up is the following two questions:

• Not everyone in the team can answer or solve the problem in a complete way, so many people are thinking about these problems again and again.
• How to avoid the wrong operation caused by the product is not complete.

These two problems are also the purpose of our workflow.

I'll take a look at some of the concepts and lifecycles of git that apply to my job responsibilities.

After describing the responsibilities clearly, the workflow is as follows:

Finally, it is hoped that a unified git-developed workflow will continue to iterate quickly. Or the ultimate goal is to hope that the team members only focus on the business, business-independent through the Convention, norms, processes to circumvent .

Git-based workflow