...
4. Rebase the upstream development branch into your topic branch. Do not merge master into your local PR branch (this is the lazy approach to dealing with committed code locally in a branch, and then realizing that your PR isn’t merge-able because HEAD has changed). See https://git-scm.com/book/en/v2/Git-Branching-Rebasing if you need more help.
Conventional Commits
EdgeX Foundry developers follow the Conventional Commits specification for commit messages when submitting pull requests. The specification aims to make commit messages more human and machine readable. Conventional commit messages can be used to automatically generate release notes. They also help developers focus PRs into smaller "chunks" of related functionality.
When you submit your pull request (PR) against an EdgeX repository, you must provide a Conventional Commit type and scope in the subject line of your commit. The type specifies the nature of the pull request. The scope provides the service or component being addressed or context of the pull request. In addition to type and scope, you must describe your commit. You can optionally provide additional comments (or commit body) and footers.
The types and scope will vary per repository. The following is the current standard as of 2020-09-24
From: EdgeX-TSC-Core@lists.edgexfoundry.org <EdgeX-TSC-Core@lists.edgexfoundry.org> On Behalf Of Jim White
Sent: Thursday, September 24, 2020 12:12 PM
To: Core WG <edgex-tsc-core@lists.edgexfoundry.org>
Subject: [Edgex-tsc-core] Conventional Commits
Hello core working group members. Per the Core WG meeting today, I am looking for feedback on our upcoming adoption of conventional commits specification across repositories under Core WG purview. Thanks to Mike Johanson, the types and scopes for edgex-go are to be set at these:
edgex-go
types: feat (for feature), fix, docs, style, refactor, perf (for performance), test, build, ci, revert
scopes: core-data (or data), core-metadata (or metadata or meta), core-command (or command or cmd), snap, docker, security, scheduler, notifications, sma, deps (for dependencies), all
For the other repositories, I propose the following.
all mods (bootstrap, core-contracts, messaging, registry, configuration)
types: feat (for feature), fix, docs, style, refactor, perf (for performance), test, build, ci, revert
scopes: [no scope for general code or scope does not apply], models, errors, clients, config, docker
edgex-docs
types: feat (for feature), fix, style, build, ci, revert
scopes: [no scope for general docs or scope does not apply], intro (and getting started), api, adr, design, examples, microservices, ref (for reference)
edgex-cli
types: feat (for feature), fix, docs, style, refactor, perf (for performance), test, build, ci, revert
scopes: [no scope for general code or scope does not apply], res, samples, config
edgex-ui-go
types: feat (for feature), fix, docs, style, refactor, perf (for performance), test, build, ci, revert
scopes: [no scope for general code or scope does not apply], image
docker-edgex-consul
types: feat (for feature), fix, docs, refactor, perf (for performance), ci, revert
scopes: [no scope for general code or scope does not apply], config, scripts (or bin)
docker-edgex-mongo
types: feat (for feature), fix, docs, refactor, perf (for performance), ci, revert
scopes: [no scope for general code or scope does not apply], config, scripts (or bin)
developer-scripts
types: feat (for feature), fix, docs, style, refactor, perf (for performance), test, build, ci, revert
scopes: no scope or compose or source (for compose source)
edgex-examples
types: feat (for feature), fix, docs, style, refactor, perf (for performance), test, build, ci, revert
scopes: app (for app services), device (for device services), temp (for templates), security, all, or no scope if it does not apply to these
Please weigh in with any other changes or additions. We'll resolve and adopt with next week's meeting.
Jim White
Examples of proper messages (in the context of sample Git CLI commands) are:
- git commit -s -m "fix (core-data): repair the incorrect status code returned by the get all query"
- git commit -s -m "build (all): upgrade the services to Go 1.15"
If you do not provide type in your commit message, an automated GitHub bot will flag your pull request and it will fail its checks. When your pull request has failed checks, it cannot be merged until the problem is corrected. If you do not provide scope, the EdgeX reviewers are expected to flag your pull request and ask that you make a change to provide a scope. Without reviewers approval, your pull request does not pass the reviewer check and it cannot be merged.
The body of the commit should contain a reference to issue that is addressed (closes and/or fixes). Example:
- git commit -s -m "fix(core-data): fixed some big error description" -m "fixes: #123"
- git commit -s -m "fix(core-data): fixed some big error description" -m "closes: #123"
EdgeX GitHub Getting Started
...
Note: While working alone on a local branch that has not yet been pushed, it's fine to use commits as temporary snapshots of your work. However, it still holds true that you should apply all of the above before pushing it.
Commit Messages
EdgeX will follow will well-established conventions for creating consistent, well written Git commit messages. Just follow Follow the seven rules below and you shouldn’t run into any problems.
...
You can add a commit subject line and multiple message bodies like this:
git commit –s –m “This “fix(core-data): This is the subject; keep to 50 char” –m “This is the first line of the message body"$'\n'"This is the second line of the message body."$'\n'"Keep all message lines to 72 char.”
...