Accidents encountered in code management

Code is a very important asset in the entire r&d activities of an enterprise. If the code has problems, the products and services provided to customers will cause unpredictable accidents due to these problems, which will have a negative impact on the enterprise. Therefore, how to make code management more orderly and reliable is an urgent problem for the majority of enterprises and RESEARCH and development teams.

An enterprise’s research and development team is composed of multiple developers. There are differences between the different developers, technical level, the area also has difference, and the process of software development is a process of collaboration, team members using Gitee time is not long, also in slowly learning to git, so in the process, there must be some greatly small accident, the following three conditions: you must be met:

• Content developed by several people influences each other
• I don’t know who changed the important branch code, or simply delete the branch
• When Code is merged, CodeReview is superficial or has no CodeReview section at all

Today we’re going to take a look at all three of these issues and share with you how Gitee enterprise code management can solve these problems and make your enterprise code management more orderly and reliable.

Gitee Enterprise Edition practices

1. Branch model

Both large and small enterprises, at the beginning, will be confused about how to plan the branch model. One of the branches we see and hear most often is the git-flow branch model shown above. However, git-Flow branch model cannot be adapted to every enterprise. Branch model is the same as other management modes, and an enterprise needs to have its own model.

If an enterprise wants to build a branch model suitable for its own business characteristics, it should first understand the purpose of branches:

• Manage the branch of a unique product version

  The master branch is used to manage the most stable code for the product, and if the development scenario within the enterprise is very simple, then development and distribution can be done directly on the Master branch. As the team size increases, stable releases of product code are developed in other branches, and stable releases are folded into the Master branch when completed.

• Make an updated branch

  This is what the Develop branch does in Git-flow. Since the Master branch only manages stable release code, the development process commits the code to the Develop branch and can release the Develop code to the test environment. When the test is complete and released, the contents of the Develop branch can be merged into the Master branch. This creates a stable release branch and an updated development branch.

• Fix emergency defect branch

  After the product is released, there are likely to be urgent production defects that need to be fixed and tested before a new production version can be released. However, since the develop branch has a lot of new features, it is not possible to make changes directly from the development branch, and direct changes to the master branch will affect the management of the release version. Therefore, you can create a hotFix branch from the Master branch for emergency bug fixes. We do fixes and tests in the HotFix branch and then merge them into the Master branch to complete the release.

• Separate requirements development branches

  As the development team grows in size, there are more developers in the team, and the code of each of them will affect each other. Therefore, you can create your own development branch for different requirements and submit the feature branch in Git-flow. Each developer works on the development branch feature of their own requirements, and when it is finished, it is incorporated into the Develop branch. This ensures that the contents of the Develop branch are completed requirements that can be tested at any time.

• Set up a dedicated publishing branch

  As the team grows in size, in order to make the development process independent from the production verification process, when a release is required, a release branch can be pulled. Tests and defect fixes can be carried out on the release branch, and then released to the Master branch after passing the release. This way, neither the merge of the new develop branch features nor the validation of the published content will be affected.

As you can see from the above process, the branch model must be related to the development work pattern and can be adjusted to the team size and business specific. For example, a branch will be created according to the different customer versions of the team. The branch model that suits the characteristics of your team is the best.

2. Protect the branch

The code on our important branch is not normal due to the misoperation of the developers, or the important branch is deleted, which will cause great losses to our enterprise and make us spend a lot of time to fix these problems. Therefore, Gitee Enterprise edition also provides relevant features to minimize the occurrence of similar problems.

Gitee provides branch protection in branch management. In the enterprise, we can set the development leader as the administrator of the warehouse, and other developers as developers. This allows the development manager to set key branches such as Master and Develop as protected branches.

Installed protection branch, with ordinary developers, developers permissions cannot be directly submitted to protect the code branch, and also can’t will protect the branch to delete, can only be operated by a user with administrative privileges, thus greatly important code version control, to help the team will not affected by the developers accidental operation.

As a development leader with administrator rights, you can grant code push and code merge rights to other developers by setting protective branch rules. This allows team members to help with code reviews, maintain and protect the code on the branch, and prevent the branch from being deleted by mistake.

However, if the protection branch is set, the average developer can not directly commit code to the protection branch, so how to merge the code into the protection branch? This brings into play an important feature of Gitee Enterprise edition: Code review (Pull Request).

3. Code review (Pull Request)

After completing the development of their own functions, developers need to merge the content of the feature branch into the integration development branch Develop. Then, they need to submit their developed content to the development leader for review through the Pull Request function. After passing the review, You can merge the code into the target branch.

Through the way of code review, the team can ensure that every time the important branch is modified, the development leader can clearly see the content of the code modification and review, and the content of every code merge is recorded to ensure the reliability of the code merge.

3.1 Developers submit code reviews

Developers use the code review function to create a Pull Request, select the branch on which their development task resides, and select the target branch that needs to be plugged in. Fill in the title and description of the submitted change, and tell the reviewers what the code needs to be included in this time.

When the developer submits, he or she can select the reviewers who will be required to review the merger. The administrator can set the list of people to be reviewed by the system. This way, the code can only be merged after it has been approved by the selected reviewers and testers.

When creating a code review, you can see how many commits and how many files you changed while developing the code.

Once the information is filled in, a code review request is created for reviewers to review the code merge.

3.2 The person in charge checks the submitted content

After reviewing the code review request submitted by the developer, the reviewer can view the content of the code review, including the description of the code review, the related task information, and the background information of the code submitted by the developer, so as to help the reviewer better review the code.

During the review, the most important thing the reviewer needs is the document change information. The reviewer can see all the different files between the branch information submitted by the developer and the target branch that needs to be plugged in, and the modified content is highlighted so that the reviewer can quickly locate the required content.

When problems are found, comments can be added directly between the lines of code to point out the developer’s coding problems, and the developer can fix their code after seeing the problems given by the reviewer.

Reviewers can review one file at a time and add their own comments. If there are major problems with the code, they can directly reject the review request and the rejected code cannot be added to the target branch.

3.3 Merge the review contents after code approval

When a developer enters a review request he or she has created, he or she can see the reviewer’s comments on their code and make code changes based on the comments. Resubmit the code after it has been modified.

The reviewer needs to review the code submitted by the developer again. If the code meets the inclusion criteria, the reviewer can click “Pass the review” to merge the code. After clicking merge branch, the code completed by the developer can be merged into the target branch, completing the whole process of code integration.

After the code review is completed and the code is integrated into the target branch, the content of the code integration and the content of the code review can all be seen in the historical merge of the code review, which is convenient for us to follow up the code changes.

3. Summary of code management practices

By establishing a branch model within the enterprise that meets the characteristics of the enterprise development team, and through the branch protection function provided in Gitee Enterprise Edition and the most important Pull Request process, we can ensure that we can make the code management more orderly and reliable through Gitee Enterprise Edition. Help enterprises avoid business losses caused by confusion in code management.

Gitee Enterprise edition also has a number of features that can help companies in their R&D activities to greatly improve their r&d efficiency and code quality. In the future, we will continue to output the practice of project management and code management to help enterprise users to better manage R&D on Gitee, so that the r&d speed of enterprises can closely follow the pace of enterprise business development.