我正在尝试适应本文中描述的传统提交消息。

这是文章的一个片段：

允许<type>值：

feat (new feature)
fix (bug fix)
docs (changes to documentation)
style (formatting, missing semi colons, etc; no code change)
refactor (refactoring production code)
test (adding missing tests, refactoring tests; no production code change)
chore (updating grunt tasks etc; no production code change)

但有时有些变化很难归类为此类。我将列出一些关于使用哪种类型感到困惑的更改

在这种情况下我应该使用什么类型

1. 我在现有组件上添加了 css 样式（react、Angular、Vue 等）
2. 我在项目中编辑了配置文件，例如package.json、.prettierc等。
3. 重命名文件
4. 删除文件

根据传统的提交，单纯的 UI 更改应该如何分类？例如，假设注销按钮从屏幕底部移动到顶部，文本旁边添加了一个图标，并且有一个新的动画。除此之外，从功能角度来看没有任何变化。

我的困惑来自于这个（可能是错误的）推理。您不能使用以下任何一项，因为：

\n
• 壮举：这不是一个新功能
\n
• 修复：没有任何需要修复的错误
\n
• perf：未涉及性能
\n
• 重构：这可能是遵循Angular重构定义“既不修复错误也不添加功能的代码更改”的情况，但不使用重构的维基百科定义“代码重构是重组现有计算机代码的过程\xe2\” x80\x94更改分解\xe2\x80\x94而不改变其外部行为”
\n
• 样式：不影响代码含义的更改（空格、格式、缺少分号等）。不言而喻，事实并非如此
\n

可以使用感叹号在语义发布中处理主要版本更改（也称为重大更改）吗？

git commit -m \'feat!: this is breaking, but is not recognized by semantic-release\'\n

传统的提交指南表明，可以在页脚中使用页眉中的感叹号来标记重大更改。

这是我一直在测试的工作流程

安装存储库 \xe2\x9c\x93

git init\ngit remote add origin git@github.com:klueless-io/k_genesis.git\ngit branch -M main\ngit add .\ngit commit -am \'first commit\'\n# Artificial starting version number\ngit tag v0.0.18 -a -m \'k_genesis initialize repository\'\ngit push -u origin main --tags\ngit hist\n

删除单个文件并将其称为新功能 \xe2\x9c\x93

rm a1\ngit add .\ngit commit -m \'feat: remove a1\'\ngit hist\n

npx semantic-release --no-ci\n

我有一个 Github 存储库，在本地安装了commitlint 和 husky，并希望在验证拉取请求时设置一个在每次推送提交时运行 commitlint 的工作流。在主分支上，较旧的提交不遵循传统的提交规则。

我根据此评论创建了一个单独的分支

https://github.com/conventional-changelog/commitlint/issues/586#issuecomment-657226800

我从这个工作流程开始

name: Run commitlint on pull request

on: pull_request

jobs:
  run-commitlint-on-pull-request:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Setup Node
        uses: actions/setup-node@v2
        with:
          node-version: 14.x

      - name: Install dependencies
        run: npm install

      - name: Validate all commits from PR
        run: npx commitlint --from HEAD~${{ github.event.pull_request.commits }} --to HEAD --verbose

我按照传统的提交规则又做了两次提交并开始了拉取请求

• 我预计工作流不会运行，因为我还不存在于主分支上。
  • 实际上它运行
• 我期望工作流程只检查 PR 提交
  • 工作流失败，因为它开始验证主分支中的每个提交。而且因为我知道较旧的提交不遵守规则，所以这永远不会通过。

我想到的第一个解决方案是重新设置所有内容并重命名每个提交以遵循规则，但这需要付出巨大的努力。

我不确定我是否必须在这里改进这条线

npx commitlint --from HEAD~${{ github.event.pull_request.commits }} …

常规提交定义了几种类型提交信息喜欢feat，fix，chore，ci等。

我的问题是关于工作流程，如果我正在处理一个范围跨越几天工作的功能。作为一名优秀的开发人员，我想尽早并经常提交，但传统提交意义上的功能被定义为：

feat：该类型的提交为feat代码库引入了一个新功能（这与语义版本控制中的 MINOR 相关）。

所以这种类型的提交应该只使用一次（否则，CHANGELOG从这些提交中生成的将列出许多功能，而这些功能实际上只是特定功能的一部分）。

我想知道尽早并经常使用常规提交解决提交（和推送）的常见工作流程是什么？

每个人都会把他们的提交压缩成一个feat: ...类型提交吗？还有其他工作流程吗？

在压缩feat提交之前使用哪种类型的消息？

设置

我有几个 gitlab 存储库，其中一般设置涉及一个master分支、一个stage（预发布）分支和一个dev分支。

所有 3 个分支的推送权限均被禁用。

工作流程是从dev分支中派生任何修补程序、错误修复和功能。当您对发布感到满意时，您将向 提交合并请求dev。最终，当内部准备好稳定的构建时dev；将为该分支提交合并请求stage。最后，当您对预发布感到满意时，您将提交分支的合并请求master。

我配置了 CI/CD，以便通过自动生成文件从master和分支自动执行测试、构建和部署。分支部署到 UAT s3 Bucket 并部署到生产 s3 Bucket。stageCHANGELOG.mdstagemaster

部署是通过Semantic Versioning 2.0.0它来处理的，它负责更新版本、生成变更日志和部署。

我有一个与上面描述的类似的设置，除了它是一个 monorepo，所以我用来Lerna处理发布（部署）和{"conventionalCommits": true}复制Semantic Versioning 2.0.0的行为。我在 monorepo 中使用独立版本控制。

和 的Semantic Versioning 2.0.0设置都Lerna强制master分支始终位于 和 分支之后或等于stage和dev分支；并且stage分支始终位于分支后面或等于dev分支，就像级联效应一样。

dev>= stage …

我创建了一个提交，目的是取消隐藏某个功能，代码更改是仅取消注释某些代码行并显示该功能，因此现在该功能将显示给用户。

这个提交类型应该是feator 吗chore？

我想应该是chore因为它没有\xe2\x80\x98将该功能添加到代码中，只允许显示，但从用户POV来看这是一个新功能，您对此有何看法？

我已被添加到一个存储库，该存储库使用语义发布来自动提升 NPM 包的版本。该存储库使用常规提交规范，并且自述文件非常有限。

如果我要创建一个feature/ABC-123包含新功能的分支，这是否意味着我所做的每个提交都应该具有以下提交结构，feat: my message related to this commit或者我应该只有 1 个feat提交，其余的chore或其他类型不会提高存储库的版本？

或者我不需要担心这个问题，因为分支是这样的feature/ABC-123，因此语义发布知道将包提高 1 个次要版本，因为它位于功能文件夹中？

希望以上内容有意义，但如果没有的话，这里是一个提交历史记录示例：

feat: add product card basic layout
feat: add title to product card
test: add unit tests to product card
feat: add image to product card
chore: update breakpoints for card
test: add more unit tests

上面的示例是否会像我使用过 3 次那样将 NPM 包提高 3 个次要版本feat，或者仅提高 1 个次要版本？或者这并不重要，唯一重要的是压缩提交并确保feat: added …

根据常规提交规范， Lerna 似乎无法3.20.2升级预发布版本（例如） 。1.0.0-alpha.0

如果您想尝试一下，我做了一个最小的可重复示例。

假设我们有两个 Lerna 管理的存储库，都包含三个子包。一个仓库有“生产”包，另一个仓库有“预发布”包：

dev (or dev-prerelease)
  |-- packages
  |   |-- major
  |   |   |-- package.json (1.0.0 or 1.0.0-alpha.0)
  |   |-- minor
  |   |   |-- package.json (1.0.0 or 1.0.0-alpha.0)
  |   |-- patch
  |   |   |-- package.json (1.0.0 or 1.0.0-alpha.0)
  |-- package.json
  |-- lerna.json

然后，我在两个存储库中进行以下提交：（提交遵循常规提交规范）

• 主要包中的重大更改
• 小包中的新功能
• 修复补丁包中的bug

并在两个存储库中运行此命令：

npx lerna publish --conventional-commits --yes 2>/dev/null

观察结果

“生产”存储库的软件包根据常规提交规范进行更新：

Changes:
 - major: 1.0.0 => 2.0.0 (private)
 - minor: 1.0.0 => 1.1.0 (private)
 - patch: …

我正在尝试在我的 javascript 项目中使用标准版本。我将release脚本添加到我的 package.json 中：

"scripts": {
    ...
    "release": "standard-version"
}

我的问题是我向 git 存储库添加了一个提交，并显示以下消息：

feat: test

我跑npm run release，它增加了项目的补丁版本。

所以我的初始版本是0.2.1（标签：v0.2.1），它是0.2.2用此提交消息生成的

chore(release): 0.2.2

为什么不增加小版本？