...
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 helps 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 title and message 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 tables below provide the types and scopes for edgex-go as an example.
types | scope |
---|---|
feat (for feature) | core-data or data |
fix | core-command or command or cmd |
docs | core-metadata or metadata or meta |
style | snap |
refactor | docker |
perf | security |
test | scheduler |
build | notifications |
ci | sma |
revert | deps (for dependencies) |
common | all (applying to all services) |
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.
EdgeX GitHub Getting Started
...