...
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 tables below provide the types and scopes for edgex-go as an example.
| types |
|---|
| feat (for feature) |
| fix |
| docs |
| style |
| refactor |
| perf |
| test |
| build |
| ci |
| revert |
| common |
...
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.
...