preface

What is a front-end specification

Front-end specification is a set of standards and rules for front-end development behavior

Meaning of norms

  • Improve development efficiency, team cooperation efficiency, reduce communication costs
  • Reduce the cost of integrating new members into the team, and also avoid digging holes to a certain extent
  • Achieve highly uniform code style, improve readability, convenient review, on the other hand, can improve the maintainability of the project

Specification object (process specification)

  1. Development process specification
  2. Interaction, design specifications
  3. Interaction, design and front end docking gauge
  4. Front-end development specification
  5. Specification for back-end interfaces and data structures
  6. Specifications for front-end and back-end interconnection
  7. Front-end code of conduct

Project development process specification

UI design specification

What are the design specifications?

A normative document that manages and summarizes design elements (Logo, color, font, typography, etc.) and common component resources in the interface and UI.

What is the role of a design specification?

Design specification can solve many problems for the team and greatly improve the efficiency of team collaboration. Its role is mainly reflected in the following aspects:

1. Solve the confusion in the use of team collaboration project controls

A large project with dozens or even hundreds of pages is usually done by a team. If there is no established design specification, it is almost impossible to maintain the uniformity of the same control on different pages. However, if a UI designer creates a design specification before many people collaborate on a project, and the rest of the team follows it, visual unity can be effectively controlled and productivity can be much easier.

2. Maintain brand consistency during product iteration

Iteration is indispensable in the later maintenance process of the product. Without a design specification, after many iterations, it is possible to forget the original design. The LOGO style in version 3 is likely to diverge further and further from version 1. With design specifications, it is easy to maintain the original intention and maintain the brand image in the later iteration process.

3. Greatly improve the work efficiency of developers and reduce unnecessary code duplication

With a design specification, developers can quickly invoke a set of code, greatly increasing productivity.

Existing mature open source component libraries

For Design specifications, it is highly recommended to look at Ant Design’s Design principles, Design values (natural, deterministic), and understanding of human-computer interaction

  • Ant Design
  • Element UI

Development process specification

Git Flow specification

Git installation and configuration and basic use

  1. Download the installation package from the official website and install it manually.
  2. Open the Git Bash command line tool and run the ssh-keygen -t rsa -c emer-addresss command to generate a key pair.
  3. SSH /id_rsa.pub. Copy the contents of the. SSH /id_rsa.pub file in the user directory to the Key.
  4. Click New Project, then click Create Project to Create a repository, click Activity, and click SSH to copy the address in the SSH sidebar.
  5. Open the Git Bash command line tool, switch to an appropriate directory, and use the Git clone command to clone the repository you just copied.
  6. Git config –global user. Email your-email
  7. Git config –global user.name your-name

Execute command:

  1. Git status: check the current status and find untraced files
  2. Git add. Adds all files in the current directory to the staging area
  3. Git diff compares the difference between the current workspace and the staging area
  4. Git status: indicates that a file is not committed
  5. Git commit -m “comment” to commit the staging contents to the local repository
  6. Git push -u origin master
  7. Git log to view commit logs

Git local branch management

Create, merge, and delete branches

  1. Git branch, showing all branches
  2. Git branch -a displays all local and remote branches
  3. Git checkout -b b1, create a branch called b1 from the current branch and switch to branch B1
  4. Git checkout master
  5. Git merge b1, merge b1 into master
  6. Git branch -d b1 indicates that branch B1 cannot be deleted

Git Tag management

Create and delete labels

  1. Git tag t1 creates a tag named T1 from the current branch
  2. Git tag -d t1

Naming rules

  • Each submission must be annotated, and if it is a Bug fix, please add a Bug number
  • Create a feature branch with a name starting with feture/ and adding the feature name
  • Create a release branch with a name starting with release/ and a pre-release version number
  • Create a Bug fix branch with a name starting with hotfix/ and a Bug number
  • Create a label with a name starting with tag/ and a release number
  • The –no-ff parameter must be used when merging branches to preserve the merge history

Branch model

Overall flow chart:

Main branch (Protection branch)

The main branch of develop is the one that stabilizes code and prepares it for production.

Auxiliary branch

1. Feature branches

Created from the Develop branch for feature development and merged back into the Develop branch (it is recommended to create merge Request merges online). Operation process:

  1. Git checkout -b feature/ feature-name develop branch
  2. Git Checkout Develop, merge back to the Develop branch
  3. Git merge –no-ff feature/ feature-name
  4. Git branch -d feature/ feature-name: Deletes a feature branch
  5. Git push Origin Develop to push the merged Develop branch to a remote repository

The branch relationship is similar to the following figure:

2. Publish branches

Created from the Develop branch for pre-release versions to allow minor bug fixes and then merged back to Develop and Master (recommended to create merge Request merges online). Operation process:

  1. Git checkou -b release/1.2 develop
  2. Git checkout master
  3. Git merge –no-ff release/1.2
  4. Git tag 1.2, a tag from the master branch
  5. Git checkou develop, switch to the Develop branch, and prepare the merge
  6. Git merge –no-ff release/1.2
  7. Git branch -d release/1.2

3. Repair branches

Created from the Master branch for Bug fixes on the production environment and merged back to Develop and Master (recommended to create merge Request merges online). Operation process:

  1. Git checkout -b hotfix/1.2.1 master
  2. Git checkout master
  3. Git merge –no-ff hotfix/1.2.1
  4. Git tag 1.2.1 creates a tag for the master branch
  5. Git Checkout Develop, switch to the Develop branch, and prepare to merge
  6. Git merge –no-ff hotfix/1.2.1
  7. Git branch -d hotfix/1.2.1

The branch relationship is similar to the following figure:

Reference:

1.Git – website

2,Git – a concise guide

Git Rebase Flow

Git basic process steps

When you want to develop a new feature, cut off a branch from Master

  • // 1. Pull the latest code
  • git pull –rebase
  • // start a new branch
  • Functional Branches:
  • git checkout -b feat/xxxx
  • Repair branch:
  • git checkout -b fix/xxxx

After developing merge Request, if there is no conflict in the merge Request, it is enough to notify the corresponding personnel directly. If there is conflict, please follow the following steps

Second, after the function is developed, it needs to be merged into master. Rebase the latest master branch and merge it

  • // 1. Switch the master branch
  • git checkout master
  • // 2. Pull the latest code
  • git pull –rebase
  • // 3. Switch to your branch
  • git checkout feat/xxx

After the above steps are complete, follow the following steps

  • // 1. Rebase on master
  • git rebase master
  • // 2. If a conflict occurs, manually resolve the conflict
  • git add .
  • // 3. Move on to the next conflict
  • git rebase –continue
  • // 4. If all is settled
  • git push –force-with-lease
  • // 5. We are done, let Mr Directly merge the code

Some other commands for rebase

  • // If the current log is not needed
  • git rebase –skip
  • // If the current rebase needs to be terminated
  • git rebase –abort

Git Commit specification

Commit specification format

The most popular Git Commit specification is the one used by angular. js projects: the Header section is a single line with three fields: Type (required), scope (optional), and subject (required).

1, the Header

type:
  • Feat: New Feature
  • Fix: Fixes bugs
  • -Jenny: There are some docs.
  • Style: format (changes that do not affect code execution)
  • Refactor: refactoring (i.e. code changes that are not new features or bug fixes)
  • Test: Adds a test
  • Chore: Changes to the build process or helper
scope

Scope is used to specify the scope of the commit impact, such as the data layer, control layer, view layer, and so on, depending on the project. For example, in Angular, $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc. If your changes affect more than one scope, you can use * instead.

subject

Subject is a short description of the commit purpose, no more than 50 characters long. Other notes:

  • Start with a verb and use the present first-person tense such as’ change ‘rather than’ changed ‘or’ changes’
  • The first letter is lowercase
  • Ending without a period (.)

2, the Body

The Body section is a detailed description of the commit, broken into multiple lines. Here’s an example.

  1. More detailed explanatory text, if necessary. Wrap it to
  2. about 72 characters or so.
  3. Further paragraphs come after blank lines.
  4. – Bullet points are okay, too
  5. – Use a hanging indent

Note:

  • Use the present tense of the first person, such as “change” instead of “changed” or “changes”.
  • Never forget that line 2 is blank
  • Explain the motivation for the code change and how it compares to previous behavior.

3, Footer

The Footer section is only used in the following two cases: Incompatible changes If the current code is incompatible with the previous version, the Footer section begins with BREAKING CHANGE, followed by a description of the CHANGE, the reason for the CHANGE, and the migration method.

  1. BREAKING CHANGE: isolate scope bindings definition has changed.
  2. To migrate the code follow the example below:
Copy the code
  3. Before:
Copy the code
  4. scope: {
Copy the code
  5.   myAttr: 'attribute',
Copy the code
  6. }
Copy the code
  7. After:
Copy the code
  8. scope: {
Copy the code
  9.   myAttr: '@',
Copy the code
  10. }
Copy the code
  11. The removed `inject` wasn't generaly useful for directives so there should be no code using it.
Copy the code
Close the Issue

If the current commit is for an issue, you can close the issue in the Footer section.

  1. Closes #234
Revert

In a special case, if the current COMMIT is used to undo a previous COMMIT, you must start with REVERT:, followed by the headers of the revoked commit.

  1. revert: feat(pencil): add ‘graphiteWidth’ option
  2. This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

The format of the Body part is fixed and must be This reverts commit < Hash >., where hash is the SHA identifier that was revoked. If the current commit is in the same release as the revoked commit, neither of them will appear in the Change log. If the two are published at different times, the current commit appears under the Reverts subheading of the Change log.

For example

Git Commit (feat(login)) Add Login Module Feat indicates the commit type, login indicates the domain scope, and Add Login Module indicates the short description of subject for the commit purpose

Git Commit Git Cz

Git CZ tool can be used to achieve standardization. I have also studied and tried it, and it is not bad. Here’s how I tried it:

Git cZ

Git cZ
  1. Install the plugin Commitizen globally
  1. npm install -g commitizen
  1. Go to the git project initializer (install + Configure) where you want to use git cz.
  1. commitizen init cz-conventional-changelog –save –save-exact
  1. Now you can use git Cz instead of git commit to generate a professional commit.
Git cz

Just follow the prompts step by step!

  1. git cz
  2. # specify the type of commit
  3. ? Select the type of change that you’re committing:
  4. This is used to describe the scope of the change in the format of project name/module name
  5. ? What is the scope of this change (e.g. component or file name): (press enter t** **o skip)
  6. # Give a short description of the changes
  7. ? Write a short, imperative tense description of the change (max 83 chars): (11)
  8. Long description of changes
  9. ? Provide a longer description of the change: (press enter to skip)
  10. Is # a destructive change
  11. ? Are there any breaking changes?
  12. Does # affect any issue? If yes, enter the issue number next
  13. ? Does this change affect any open issues?

Commitlint + husky constraint

1. Install CommitLint

  1. # Install and configure if needed
  2. npm install –save-dev @commitlint/{cli,config-conventional}
  3. Initialize the configuration file
  4. echo “module.exports = {extends: [‘@commitlint/config-conventional’]};” > commitlint.config.js

2. Install HusKY V4

  1. # Install Husky v5
  2. NPM install [email protected] – save – dev
  3. # or
  4. Yarn add [email protected] – dev

3. Add hooks to package.json

  • “husky”: {
  • "hooks": {
Copy the code
  •   "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
Copy the code
  • }
Copy the code
  • }

4. Submit the command test

  1. git commit -m “foo: this will fail”
  2. Husky > commit- MSG (node v10.1.0)
  3. No staged files match any of provided globs.
  4. ⧗ input: foo: this will fail
  5. * Type must be one of [build, chore, CI, docs, feat, fix, perf, Refactor, Style, test] [Type-enum]
  6. * Found 1 problems, 0 warnings
  7. ⓘ Get help: github.com/conventiona…
  8. husky > commit-msg hook failed (add –no-verify to bypass)

Refer to the website CommitLint:commitlint.js.org/

Version of the specification

Version format: Major version number. The second version number. The increment rule is as follows:

  1. Major version number: When you make incompatible API changes,
  2. Minor version number: When you make a backward-compatible feature addition,
  3. Revision number: When you make a backward compatible problem fix.

The prior version number and version build metadata can be added to the major version number. Second version number. Revision number “is followed as an extension. Reference: 1. Semantic version