Coding Devops: code specification and git flow



About Instructor

Yang Zhou
Architect of coding Devops
Coding preacher

Continuous entrepreneur, DIY / Linux player, Zhihu xiaov, once worked as a back-end developer in Innovation workshop and Baidu. With more than ten years of experience in front-line R & D and team leadership, he has experienced various projects in tob, TOC, o2o, domestic and overseas, witnessed the birth of cloud computing era, and is good at R & D best practices: code review, Devops, GIT workflow, agile development, architecture, geek office hardware.


With the rise of Tob (enterprise services) and the maturity of TOC (consumer Internet) products, the loss caused by online failures is increasing, and the code quality is becoming more and more important. Quality built-in is one of the core concepts of Devops. Moreover, the best practice of improving code quality is not only suitable for new projects, but also provides a perfect progressive scheme for old projects.

Common code quality problems

  • English spelling mistakes
  • Divulge password
  • Invalid comment
  • Magic numbers
  • Hard code
  • Indentation and other code style problems

How to solve code quality problem

Code Review

The first step is to lock the trunk, prohibit direct submission, and adopt multi branch development. First pull a branch, modify the code and push the branch, and then initiate a merge request for colleagues to review the code. A more advanced technique is to automatically create a merge request when pushing code, and the temporary branch will be automatically deleted after merging.

After the merge request is created, the link needs to be sent to colleagues for review, which is also a concept advocated by agile development – efficient communication. Generally, you choose to notify your colleagues directly through the enterprise chat tool. If you don’t notify them in time, your colleagues may see it for several days, delaying the progress of the project. After receiving the merger request, please do your best to review on the same day without delay.

It is important to note that each time you submit code, you only submit one thing with the smallest granularity, that is, atomic submission, instead of submitting several things at one time. For example, there are three things, one of which is fixing bugs. As a result, if there is a problem with fixing bugs, it needs to be rolled back. If three things are submitted in three times, the problem can be easily rolled back, and the other two correct ones will not be affected; if they are submitted together, they cannot be rolled back.

The code review must be conducted before each code is merged to find problems and reduce faults. If the wrong code has been merged online, it will be called “fault review meeting” instead of “code review” at this time, which is meaningless.


Incremental checking of lint code specification

Lint is called code static scanner. Different languages have different lint programs and different specifications


  • When to use lint

1. It is most convenient to run in ide in real time and check while writing. The disadvantage is that everyone needs to configure it.

2. Git commit check when submitting Code: every git project has a. Git / hooks directory. Modify the pre commit script in it to intercept and check when submitting code. The disadvantage is that it can be deleted.

3. The most reliable is the server side check. When the code is pushed to the server, the continuous integration check is very reliable and will not be deleted. The disadvantage is that it is not as timely as local.

These three methods are generally used in combination.


  • Incremental check

There are many specification problems in old projects, and it takes a lot of manpower to clean them up at one time. Moreover, the more code changes at one time, the higher the risk, which may lead to online failure, especially for projects lacking automatic testing.

Therefore, incremental checking is recommended. If students are familiar with git command, it’s easy to understand. Incremental checking is git diff. When submitting locally, GIT diff can get all the new, modified and deleted files. It only needs to exclude the deleted files, pick out other files and pass them to the lint program. Students must be familiar with Linux commands, GIT commands, do not always use git graphical interface, then you will be difficult to master these contents.

Access coding help document( “incremental check” to see the complete configuration code.

Git workflow


In the era of individual combat, as shown in the figure above, a person can submit code without any workflow, just to the trunk. Now, when many people work together on a project, everyone submits to the trunk, which leads to conflicts. As shown in the figure below, for multi branch development, each requirement has a small branch for each bug, which is merged into the trunk after development.

There are two commonly used workflows. The first one is called feature branch workflow. As you can see from the figure below, two branches are pulled down from the main branch, one for login and the other for payment. After logging in, it will be merged. A bug of SMS will be fixed later, and it will be released after merging. However, the payment function is still under development, and problems will appear at this time. Originally, login and payment had to go online together, which means that two functions at the same stage in the same period depend on each other. As a result, because of the online SMS bug repair, login was brought online first, which led to problems. Therefore, this mode is not suitable for large projects, but the second one.


Simple git flow is a two branch development mode, which has a development branch besides the main branch. The development branch corresponds to the iteration in agile development. Each iteration will create a development. All the functions in this iteration will be merged into the development instead of the trunk. The trunk can be released at any time. If there is a bug, fix it on the trunk. When this iteration is over, connect development to the trunk.


Fork is not a workflow. Team collaboration must not use fork. Fork is dedicated to open source projects. When we try to modify an open source project, because we don’t have the authority to create a branch, we can only copy the project (official translation) into our own project, then pull a branch in our own project, modify the code, and finally launch a cross project merge request to merge it into the author’s open source project. If we want to develop it again later, we need to synchronize it again. Therefore, fork is only used for open source collaboration, which is not suitable for team collaboration at all. Students should not make mistakes. Specific documents can be viewed by scanning the code.



Finally, summarize the upgrade route of code quality. From the original submission of the trunk without checking the code, not checking the specification, to locking the trunk for manual inspection, and then manual inspection is too tired, I hope to do automatic inspection, and make as many things as possible automatic inspection. But there are some things that can’t be automatically checked, such as the use of Pinyin in the code and no errors in grammar; or the use of English words, such as the user’s “points” should use points instead of integral. Therefore, we can’t see that after the automatic inspection, we can directly agree to the merger. This is irresponsible. We must carry out manual inspection.

After this process, the students’ code will be very clean and beautiful, and the style of teamwork will be the same. Generally, you will choose the code specification of a well-known manufacturer in the industry rather than inventing the specification yourself. In this way, you will not be able to convince the public, and if you participate in open source projects in the future, it will be difficult to keep up with the industry.

Click to watch the course playback

Learn more about coding