Accidents encountered in code management

Code is a very important asset of an enterprise in the whole R & D activities , If something goes wrong with the code , Then the products and services provided to customers , These problems will cause unpredictable accidents , Have a negative impact on the enterprise . therefore , How to make code management more orderly and reliable , It is an urgent problem for enterprises and R & D teams to pay attention to .

The R & D team of an enterprise is composed of multiple developers . Different developers have different technical levels , There are also differences in areas of expertise , And the process of software development is a process of multi person cooperation , Team members use Gitee Time is not long. , Yes git Also slowly learning , Then there must be some big and small accidents in this process , You must have encountered the following three situations ：

• The content developed by several people affects each other
• I don't know who modified the code of important branches , Or simply delete the branch
• When merging code ,Code Review Floating on the surface or not at all CodeReview link

Today we will focus on the above three questions , Share how to pass Gitee Enterprise Edition The code hosting feature of solves these problems , Make enterprise code management more orderly and reliable .

Gitee Enterprise practice

1. Branch model

Whether it's big or small , At the very beginning , Will be confused about how to plan the branch model . We most often see 、 One of the most commonly heard branching models is the one above git-flow Graph of branching model . but git-flow Branch model of , It can't adapt to every enterprise , The branch model is the same as other management modes , An enterprise needs to have its own model .

Enterprises want to build a branch model suitable for their business characteristics , First of all, understand the purpose of the branch ：

• Manage branches of unique product versions

  master It is the branch used to manage the most stable code of the product , If the development scenario in the enterprise is very simple , Then you can go directly to master Develop and publish on branches . As the team grows in size , Under the condition of ensuring the stability of product release version code , Will be developed in other branches , When finished, merge the stable version into master Branch .

• Make branches that are updated at any time

  git-flow in ,develop Branches do this . because master The branch only manages stable release code , The development process will submit the code to develop In the branch , And you can put develop Release your code to the test environment , To complete the test 、 After the release of , And then develop The contents of the branch are merged into master Go up the branch . In this way, a stable release branch and a development branch that can be updated at any time can be formed .

• Repair branches of emergency defects

  After product launch , There is a high possibility of urgent production defects , These production defects need to be repaired , After the test , Before you can release a new production version . But because of the development branch develop Many new functions have been added , It cannot be modified directly from the development branch , Release branch master Direct modification will affect the management of release version , So you can go from master In the branch , Create a special for urgent defect repair hotfix Branch . We are hotfix Repair and test in the branch , When finished, merge to master Go up the branch , Complete release .

• Independent requirements development branch

  After the size of the development team increases , There are many developers in the team , We are developing branches together develop Coding will cause everyone's code to affect each other , therefore , Different requirements can be developed for , Create your own development branch for this requirement , stay git-flow Submitted in feature Branch . Every developer is in the development branch of their own requirements feature Upper development , After completion, close to develop in , So that's a guarantee develop The content of the branch is the completed requirements , Can be tested at any time .

• Set a dedicated publishing branch

  After the team size continues to grow , In order to make the development process independent of the production verification process , When version release is needed , You can pull a publishing Branch release Branch , stay release Testing and defect repair on branches , Pass and then publish to master Branch . such , It will not affect develop Merging of new branch functions , Without affecting the verification of published content .

From the above process, we can see , The branching model must be associated with the pattern of development work , It will also be adjusted according to the size of the team and the specific business , For example, the versions given by the team to different customers are different , A branch will be created according to different customer versions . Branch model suitable for your team's characteristics , It's the best .

2. Protection branch

Our important branch is due to developer misoperation , The code above the branch is abnormal , Or important branches are deleted , These circumstances will cause great losses to our enterprise , It will take us a lot of time to fix these problems . therefore ,Gitee The enterprise edition also provides related functions , Avoid similar problems to the greatest extent .

Gitee In branch management , It provides the function of protecting branches , In the enterprise , We can set the development leader as the Warehouse Administrator , Other developers are set to the developer role . In this way, the development leader can focus on branches such as master Branches and develop The branch is set to protected .

After setting the protection branch , Ordinary developers with developer rights , It is not possible to submit code directly to the protected Branch , And the protection branch cannot be deleted , Operations can only be performed by users with administrator privileges , This greatly helps the team to control important code versions , Not affected by unexpected actions of developers .

As the development leader with administrator privileges , You can set protection branch rules , Authorize other developers to push and merge code . This allows members of the team to help themselves with code reviews , To maintain the code on the protected Branch , It can also prevent branches from being deleted by mistake .

But if the protection branch is set , Ordinary developers cannot submit code directly to the protection branch , So how do you merge code into protected branches ？ This will use Gitee An important feature in the Enterprise Edition ： Code review （Pull Request）.

3. Code review （Pull Request）

After developers complete the development of their own functions , Need to put feature The content above the branch is merged into the integrated development branch develop above , You need to pass code review （Pull Request） function , Put the content developed by yourself , Submit to the development leader for review , After passing the review , You can merge the code into the target branch .

Through code review , It can ensure that every time the team modifies an important branch , Can let the development leader clearly see the content of code modification and review , And record the content of each code combination , Ensure the reliability of code integration .

3.1 Developers submit code reviews

Developers pass the code review function , establish Pull Request, Select the branch where your development task is located , And select the target branch to be merged . Fill in the title and description of the submitted change , Tell the reviewers what needs to be included in the code this time .

Developers can choose reviewers when submitting , Which developers are required to review this merger . The administrator can set the list of personnel for review through the system . such , It must be approved by the selected reviewers and testers , Code can be merged .

When creating code reviews , You can see that when we develop the code this time , How many submissions have been added , How many files have been changed .

After completing the relevant information , You can create a code review request , Reviewers need to review the content of code consolidation .

3.2 The person in charge checks the submission

The reviewer sees the code review request submitted by the developer , You can view the content of the code review , Contains a description of the code review , Associated task information , Understand the background information of developers submitting code , Help reviewers better review code .

At the time of review , What reviewers need most is document change information . Here, the reviewer can see the branch information submitted by the developer and all difference files on the target branch that needs to be merged , And the modified content will be highlighted for annotation , So that reviewers can quickly locate the content to be reviewed .

When you find a problem , You can add comments directly between lines of code , Point out developers' coding problems , Developers can fix their own code after seeing the problems given by the reviewer .

Reviewers can review documents one by one , Add your own review comments , If there is a big problem with the code , Review requests can be rejected directly , Rejected code cannot be merged into the target branch .

3.3 After the code is approved, the review contents will be merged

After the developer enters the review request created by himself , You can see the reviewers' comments on their own code , The code can be modified according to the review comments . Resubmit the code after the code modification is completed .

The reviewer needs to review the code submitted by the developer again , After meeting the inclusion criteria , You can click review to pass , You can merge the code . Click merge Branch , The code completed by the developer , Can be combined into the target branch , Complete the whole code integration process .

Complete code review , After the code is merged into the target branch , The content of the code , Content of code review , All can be seen in the historical merge of code reviews , It is convenient for us to trace the code changes later .

3. Code management practice summary

We establish a branch model in the enterprise that conforms to the characteristics of the enterprise development team , And pass Gitee Enterprise Edition Protection branch function provided in , And the most important code review （Pull Request） technological process , It can ensure that we pass Gitee Enterprise Edition , Make code management more orderly and reliable , Help enterprises avoid business losses caused by confusion in code management .

Gitee Enterprise Edition There are many functions in , It can help enterprises in R & D activities , Greatly improve the R & D efficiency of enterprises , And significantly improve the quality of the code . In the future, we will continue to output in project management 、 Code management practices , Help enterprise users in Gitee Better R & D Management , Let the enterprise's R & D speed closely follow the pace of enterprise business development .