Shulou(Shulou.com)06/03 Report--

This article mainly explains "what are the ways of code management workflow". The content of the explanation in this article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought. Let's study and learn "what are the ways of code management workflow"?

Centralized workflow

Centralized workflow must be very familiar to students who have used SVN. Let's think about the collaboration experience under SVN. Different developers need to submit local changes to the server in turn. If there is a conflict, resolve the local conflict first and then submit it. In this process, the remote server is like a centralized manager, managing everyone's code submission. So the development collaboration process of SVN is a typical centralized workflow.

If you switch to Git to maintain the code warehouse, but the developer is not familiar with the branching mode of Git, can you implement a similar centralized workflow with Git? The answer is yes.

Each developer clone the code of the remote warehouse into its own local warehouse, submit the code to the local warehouse first, and then push it to the remote warehouse.

This model has only one more local repository than SVN, and developers with experience in SVN can quickly become familiar with this pattern, and many companies used Git as a SVN in previous years.

From the submission record, a centralized workflow usually goes forward in a straight line, as shown in the following figure:

Centralized code submission process

Summary: this model is not recommended because it does not play the role of Git at all, which is similar to cutting vegetables with the dragon sword, which is too wasteful.

Feature Branch Workflow

There is a big problem with the centralized workflow. With the increasing number of people in the team, people may encounter conflicts every time they submit code, and submit code to resolve conflicts for an hour every minute.

In order to facilitate everyone to work concurrently, several feature branches are usually pulled based on the master trunk branch. Each developer pays attention to his own branch and submits the code directly to the local library when the code is submitted. The latest code is usually pulled before merging into the trunk branch. If there is a conflict, resolve the conflict locally first, and then submit the MR application to merge the feature branch into the trunk branch.

Feature Branch Workflow

Under the functional branch workflow, code is not incorporated directly into the trunk branch (master), but is usually submitted through other branches (Merge Request), which makes it easy and feasible to integrate some automation operations.

After submitting the MR, team members start to watch the code you write, submit comments (code review) and vote (vote), and the team committer joins or rejects your MR.

Code submission process

After a large number of new features are merged into the master branch, it is easy to cause the quality instability of the master branch. What is the problem with the instability? For example, there is a bug to be solved online, which may only need to be solved by modifying one line of code, but the master branch has incorporated a large number of new features, and the testers have not had time to test, so the safest way is to roll back the code to the time node of the last release. Is it too troublesome to modify one line of code based on this node?

In order to solve these problems, Vincent Driessen boss summed up a set of processes and specifications for Git branch management based on development practice, which are described in detail below.

Gitflow workflow

Gitflow workflow is a very mature solution at present, which defines a strict branch model around the project release, which makes the iterative process of the project smoother by assigning independent branches for code development, project release and maintenance. Different from the previous centralized workflow and functional branch workflow, Gitflow workflow has two permanent branches: the backbone branch master and the development branch develop.

Compared with the functional branch workflow, the Gitflow workflow does not add any new concepts or commands, it assigns specific roles to different branches and defines how and when they should interact. In addition to functional branches, separate branches are used for preparing releases, maintaining releases, and recording releases.

Common branches of Gitflow:

Development main branch: master branch

The code of the master branch can be deployed directly to the build environment. In order to maintain stability, the code is not modified directly on this branch, but is merged through other branches.

Development main branch: develop branch

The develop branch is the main development branch that contains all the code to be released to the next release, mainly merged by the feature branch.

Temporary branch: feature branch

The feature branch is mainly used to develop a new feature, and once the development is complete, it will be merged into the develop branch, and the feature branch will be deleted.

Temporary branch: release branch

When you need a release of a new release version, a release branch is created based on the develop branch, which is fully tested by the tester before merging the master branch and the develop branch.

Temporary branch: hotfix branch

When a new Bug is found in the build environment, an hotfix branch is created if urgent repair is needed, and after full testing, the master and develop branches are merged, and then deleted.

How do the branches work together?

(1) master/develop branch

In principle, all commit on the master branch should be marked with Tag, because in general, there is no direct commit in master.

The devlop branch is created based on the master branch and, like the master branch, is the main branch and will not be deleted.

After being pulled out of master, develop will develop independently and will not be directly related to master.

Main branch workflow

(2) feature branch

Usually a separate feature pulls out a feature branch based on develop, and there is no interaction between feature branches and does not affect each other. As soon as the feature branch is developed, it merges into the develop branch (using merge request or pull request), and the life cycle of the feature branch ends.

Feature Branch Workflow

(3) release branch

Usually, an iterative launch will pull a release branch, and all the code developed by the developer has been integrated into the develop branch. At this time, a release branch will be pulled out based on the develop branch, and the testers will test based on that branch.

Release Branch Workflow

(4) hotfix branch

The hotfix branch is created based on the master branch. After development, you need to run to both the master and develop branches, and type a tag on the master.

Hotfix Branch Workflow

Branch naming convention

The naming style of each branch can be agreed upon within the team. Here's an example, which you can refer to:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Feature branch: starts with feature_, such as feature_order

Release branch: starts with release_, such as release_v1.0

Hotfix branch: starts with hotfix_, such as hotfix_20210117

Tag tag: if it is a release branch merge, it starts with release_, if it is a hotfix branch merge, it starts with hotfix_.

Forking workflow

Forking workflow is a way of code collaboration represented by Github. Developers write code by fork the source repository. Once the pull request is launched, the source repository author can choose whether to accept the PR or not.

The following is a detailed explanation of the Forking workflow pattern through Github.

Find any Github open source project

Https://github.com/smileArchitect/JavaMap

There are three buttons in the upper right corner: Watch,Star,Fork

Watch means to follow. Once you click on it, you will be notified of any changes to the project as soon as possible.

Star is similar to giving likes. Give more likes to open source projects and encourage the authors.

Fork originally means forking, but actually means cloning. After clicking, a copy of the project will be copied to your github remote repository.

Fork example

Execute the git clone command locally to clone the code locally, after a modification operation, submit the code and push it to the personal remote repository, and then launch the pull request on the interface. The original author of the project will see the PR you submitted, and the author can choose to accept or reject it according to the quality of the submission.

Github workflow

Forking workflows are ideal for open source projects like Github, where any developer can contribute code through fork + pull request.

Thank you for your reading, the above is the content of "what are the ways of code management workflow". After the study of this article, I believe you have a deeper understanding of the way of code management workflow. Specific use also needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.