preface
I joined the iOS team of MOBILE YY in the middle of 2020, when I found that the Commit messages written by team members in the feature stage were quite random. In the integration stage, it is relatively unified:
The Git branch management model adopted by handy team and the Commit Message specification implemented by YY GitLab Server for maint branch are briefly introduced here.
The Git branch management model adopted by handy team is a branch model based on backbone: master-maint-feature, where:
master
A branch is a trunk branch used to store external releases. It exists permanently and has a long life cyclemaint
A branch is an integration branch frommaster
Branch pull-outs, used to integrate features and release versions, exist during the integration phase (during which team members commit to the branch and only commit fixes) and are part of the lifecycle (after release, merge back)master
Branches, which usually last for a while.)feature
Branches are feature branches frommaster
Branch pull-out, used to develop features, exists during the feature phase (during which team members submit feature code, fix code, etc.) and is a short life cycle (feature integration date, merge back)master
Branch, then deleted)The Commit Message specification implemented by YY GitLab Server for mainT branch requires the following submission format:
[bug id <bugId>] <subject> review by [<reviewer>] Copy the code
In order to make the Commit Message specification of hand Y project complete (there are specifications at any stage) and perfect, so as to help the team develop and maintain the project better, I formulated and implemented a new Commit Message specification of hand Y according to the actual situation and needs of the team. The specification has been running for almost a year now and has brought significant benefits to the team and the project:
- Help team members build a better sense of norms
- Help new team members understand better
Commit
andHistory of code
- Help team members get current faster
Commit
forCode Review
- Make the project more maintainable
- Other, etc.
After the acceptance of the new Commit Message specification, as a responsible development team, we felt we could share our new Commit Message specification and how we were going to ensure its implementation.
New Commit Message specification
According to the workflow of Hand Y and the existing Commit Message specification, the new Commit Message specification is divided into two versions before and after the integration point:
Feature Commit Message
Specification: applied tofeature
Branches (e.g.Yymobile_7. 41 _composite_feature
Branch), functional characteristics of the development stageMaint Commit Message
Specification: applied tomaint
Branches (e.g.Yymobile_7. 41 _maint
Branch), feature integration stage
Both versions of the Commit Message specification are described in detail below.
Feature Commit Message specification
During feature development, the Commit Message consists of three parts:
header
: mandatory; bytype
,scope
,subject
Composition; Used to describeCommit
(type, source or area of influence, summary)body
: optional; Used to describeCommit
The details offooter
: optional; Used to describeCommit
Supplementary content of
The specific format is as follows:
<type>(<scope>): <subject>
<body>
<footer>
Copy the code
Note: Parentheses () and colons (:) in the header are all punctuated in English.
Each component of the Commit Message is described in detail below.
Type (required)
Type Indicates the Commit type. The following types are available:
feat
: New feature development; Business Logic Modificationfix
: bug fixesrefactor
: Code refactoring (no business logic involved)test
: Test related changes (such as new test cases)chore
: Build tool or auxiliary tool upgrade; Changes from build tools or helper toolsrevert
: Rollback operation
The developer needs to choose the appropriate type for the actual scenario.
Note: See the Feature Commit Message Specification sample below for examples of each type of Commit Message.
Scope (required)
Scope is used to describe the source or scope of the Commit. The description format of scope is suggested as follows:
< requirement name >
: e.g.[Liu Lu] Basic channel phase ii optimization
; Commonly used infeat
scenario<bugId>
: e.g.IOSYY-38403
; Commonly used infix
scenario< module name >- >
: e.g.Follow the Tab-Live page
; Commonly used infeat/fix/refactor
scenario< Engineering related >
: e.g.Fastlane
; Commonly used inchore
scenario
Note: Select an appropriate description format based on type and actual scenario
Subject (required)
Subject is used to describe the profile of a Commit. The requirements are as follows:
- Briefly and accurately describe the changes to this submission, in no more than 80 characters
type
andsubject
Between with English colon:
separated- Don’t end with punctuation
Body (optional)
Subject describes Commit details. The requirements are as follows:
- Describe the changes to the submission in detail, such as the specific logical changes, the scope of the immediate impact, the potential impact, etc
- You can write multiple lines. Each line contains a maximum of 72 Chinese characters. You are advised to write a maximum of 200 Chinese characters
Footer (optional)
Footer describes the supplementary content to Commit, such as Isuue URL, Report ID, and Crash ID associated with the Issue that is closed, and bug ID, bug URL, and comment URL associated with the bug that is fixed.
Feature Commit Message specification example
Feat Example of logs
-
The sample a
Feat (【 Liu Lu 】 basic channel phase ii optimization): 【 Discover TAB - discover page 】 new open black chat area entrance module PM: Liu LuCopy the code
-
Example 2
Yy_ios_741_jcpdyh or HIT experiment: YY_iOS_741_jcpdyh_entranceCopy the code
-
Example 3
Feat (Memory Monitoring): MemoryDetector-YY SDK upgraded from V0.3.6 to V0.3.7Copy the code
Example log of the Fix class
-
The sample a
fix(IOSYY-38403): 【 guess you like to add tags 】 when entering the search interface, guess you like to flash a problem reason: A child module data queue asynchronous request data in the process, YYNewSearchDisplayViewController - viewWillAppear place let [words] sub-modules request data and refresh the TableView, The submodule that caused some of the data to be received prematurely (such as the submodule) renders the UI prematurely to solve the problem: Sub-modules request data queue after the completion of an asynchronous request data, YYNewSearchDisplayViewController - viewWillAppear place are allowed to make "hot word" sub-modules request data scope: potential impact search page preview 】 【 range: noCopy the code
-
Example 2
fix(IOSYY-38411): Cause: [label sizeToFit] on some iOS versions will break the constraints of the label instance, causing it to display abnormally. In addition, sizeToFit is suitable for scenarios that do not use constraints. It and constraints belong to two layout schemes: the former is the Frame layout, and the latter is the constraint layout. No more bugs see IOSYY - 38411 under remarks: http://project.sysop.duowan.com/browse/IOSYY-38411?focusedCommentId=710520Copy the code
-
Example 3
Fix (YYMobileTarget): Fix the Signing configuration for the project found that the Signing configuration for the project was changed to Auto and now ManualCopy the code
Refactor class log example
-
The sample a
Refactor (Configuration center - Broadcast room): Delete useless configurationsCopy the code
-
Example 2
Refactor (gift-paid gift broadcast): universal giftbroadcast GiftBroadcastModelCopy the code
Example of test logs
-
The sample a
Test (UseCases): adds test cases that use incorrect passwords to log inCopy the code
Chore class log example
-
The sample a
Chore (CocoaPods): Cocoapods-Binary is upgraded from V0.4.3 to V0.4.4Copy the code
-
Example 2
Chore (Fastlane): Optimize the build scriptsCopy the code
Example revert class log
-
The sample a
"Revert (YYProject): Delete from YYWidgetExtension Target "This Reverts Commit 22FD6F31 remove YYWidgetExtension Target from the main project temporarily to avoid CI build failures while the enterprise certificate is deployed.Copy the code
Maint Commit Message specification
In the integration stage of functions and features, the Commit Message is compatible with the established specification (the Commit Message specification deployed on YY GitLab Server to implement the MAINT branch), which consists of three parts:
header
: mandatory; bybugId
,subject
,reviewer
Composition; Used to describeCommit
Introduction content (type, scope of influence, summary)body
: optional; Used to describeCommit
The details offooter
: optional; Used to describeCommit
Supplementary content of
According to the rules of the HAND-Y team, during the integration test, only bugs should be fixed in principle, and optimization and reconstruction functions should not be submitted.
The specific format is as follows:
[bug id <bugId>] <subject> review by [<reviewer>]
<body>
<footer>
Copy the code
Among them:
bugId
: mandatory; Used to describeCommit
Associated Bug IDsubject
: mandatory; A cause summary describing the Bug;The number of characters does not exceed 80reviewer
: mandatory; The email username used to describe the colleague who helped you with Code Reviewbody
: optional; Definitions and requirements are consistent with those in the Feature Commit Message Specificationfooter
: optional; Definitions and requirements are consistent with those in the Feature Commit Message Specification
Example Maint Commit Message specification
- The sample a
[Bug ID ioSYy-38898] 14 System Mobile phone hot search page does not display top banner image Review by [chenzhiying]Copy the code
- Example 2
[Bug ID iosyy-32551] Review by [Chenjianfeng3] This reverts commit e4FE6fb1Copy the code
New Commit Message specification implementation and assurance
After the formulation of the new Commit Message specification, in order to verify and guarantee the effect of implementation, we decided to implement it in the Hand-Y project first: gradually help hand-Y team members to establish the awareness of the Commit Message specification specification by taking the points to the surface.
In order to ensure the effect of implementation, I synchronously developed the supporting tool YYCommitMessageLint. In order to ensure a minimum of resistance during implementation landing, YYCommitMessageLint established a goal: no constraint on projects other than The Hand Y project, and to make it as easy as possible for the hand Y team members to install the tool.
To achieve this goal, YYCommitMessageLint is designed as aPod library that is accessed through CocoaPods into the Mobile Y project. The following is the flow chart of YYCommitMessageLint accessing iOS project:
YYCommitMessageLint To access the iOS project, perform the following steps:
-
Edit the Podfile and add the dependency declaration code for YYCommitMessageLint
This is a virtual target for installing build tools and helper tools that are accessed through CocoaPods abstract_target 'YYChoreBox' do pod 'YYCommitMessageLint' end Copy the code
-
Edit your Podfile and add the function definition to synchronize YYCommitMessageLint
def syncCommitMessageLint(a) src_root = Dir.pwd pods_root = "#{src_root}/Pods" lint_dir = "#{pods_root}/YYCommitMessageLint" ifDir.exists? (lint_dir) cmd ="cd #{lint_dir}/tools/ && sh #{lint_dir}/tools/setup_single.sh #{src_root}" system(cmd) end end Copy the code
-
Edit the Podfile and execute syncCommitMessageLint in the Pod pre_Install callback
pre_install do |installer| syncCommitMessageLint() end Copy the code
YYCommitMessageLint
The limitations of
YYCommitMessageLint is suitable for a single engineering scenario — this is both its strength and its weakness. Therefore, if you want to extend its scope from “points” to “areas”, you need another transformation — since hand Y started business componentization this spring, we want those business component projects to be covered by the new Commit Message specification (in fact, in addition to the Commit Message specification, To that end, I started designing and implementing a new solution — which will be shared in the next installment.