master

分支 (3)

标签 (40)

管理

管理

master

develop

feature/seek_pos_roll_back

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.3

v0.7.2

v0.7.1

v0.7.0

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.2

v0.5.1

v0.5.0

v0.4.2

fijkplayer
/
.gitmessage.txt

<type>(<scope>): <subject>

<body>

<footer>

# -- Type --
# Must be one of the following:
# feat, fix, docs, style, refactor, perf, test, build, chore
#
# feat: A new feature
# fix: A bug fix
# docs: Documentation only changes
# style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
# refactor: A code change that neither fixes a bug nor adds a feature
# perf: A code change that improves performance
# test: Adding missing tests or correcting existing tests
# build Changes that affect the build system, CI configuration or external dependencies (example scopes: gulp, broccoli, npm)
# chore: Other changes that don't modify src or test files
#

# -- Scope --
# The scope could be anything specifying place of the commit change. For example Compiler, ElementInjector, etc.
#

# -- Subject --
# The subject contains a succinct description of the change:
# use the imperative, present tense: "change" not "changed" nor "changes"
# don't capitalize first letter
# no dot (.) at the end
#

# -- Body --
# Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes".
# The body should include the motivation for the change and contrast this with previous behavior.
# This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?


# -- Footer --
# The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
# Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.
# - Include a link to the ticket, if any.
# - BREAKING CHANGE