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:

  • masterA branch is a trunk branch used to store external releases. It exists permanently and has a long life cycle
  • maintA branch is an integration branch frommasterBranch 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)masterBranches, which usually last for a while.)
  • featureBranches are feature branches frommasterBranch 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)masterBranch, 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 betterCommitandHistory of code
  • Help team members get current fasterCommitforCode 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 MessageSpecification: applied tofeatureBranches (e.g.Yymobile_7. 41 _composite_featureBranch), functional characteristics of the development stage
  • Maint Commit MessageSpecification: applied tomaintBranches (e.g.Yymobile_7. 41 _maintBranch), 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:

  1. header: mandatory; bytype,scope,subjectComposition; Used to describeCommit(type, source or area of influence, summary)
  2. body: optional; Used to describeCommitThe details of
  3. footer: optional; Used to describeCommitSupplementary 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 Modification
  • fix: bug fixes
  • refactor: 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 tools
  • revert: 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 infeatscenario
  • <bugId>: e.g.IOSYY-38403; Commonly used infixscenario
  • < module name >- >: e.g.Follow the Tab-Live page; Commonly used infeat/fix/refactorscenario
  • < Engineering related >: e.g.Fastlane; Commonly used inchorescenario

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
  • typeandsubjectBetween 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

  1. 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

  2. Example 2

    Yy_ios_741_jcpdyh or HIT experiment: YY_iOS_741_jcpdyh_entranceCopy the code

  3. 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

  1. 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

  2. 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

  3. 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

  1. The sample a

    Refactor (Configuration center - Broadcast room): Delete useless configurationsCopy the code

  2. Example 2

    Refactor (gift-paid gift broadcast): universal giftbroadcast GiftBroadcastModelCopy the code

Example of test logs

  1. The sample a

    Test (UseCases): adds test cases that use incorrect passwords to log inCopy the code

Chore class log example

  1. The sample a

    Chore (CocoaPods): Cocoapods-Binary is upgraded from V0.4.3 to V0.4.4Copy the code

  2. Example 2

    Chore (Fastlane): Optimize the build scriptsCopy the code

Example revert class log

  1. 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:

  1. header: mandatory; bybugId,subject,reviewerComposition; Used to describeCommitIntroduction content (type, scope of influence, summary)
  2. body: optional; Used to describeCommitThe details of
  3. footer: optional; Used to describeCommitSupplementary 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 describeCommitAssociated Bug ID
  • subject: mandatory; A cause summary describing the Bug;The number of characters does not exceed 80
  • reviewer: mandatory; The email username used to describe the colleague who helped you with Code Review
  • body: optional; Definitions and requirements are consistent with those in the Feature Commit Message Specification
  • footer: optional; Definitions and requirements are consistent with those in the Feature Commit Message Specification

Example Maint Commit Message specification

  1. 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
  1. 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:

  1. 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

  2. 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

  3. Edit the Podfile and execute syncCommitMessageLint in the Pod pre_Install callback

    pre_install do |installer|
   syncCommitMessageLint()
end
Copy the code

YYCommitMessageLintThe 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.