Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

typesscope
feat (for feature)core-data or data
fixcore-command or command or cmd
docscore-metadata or metadata or meta
stylesnap
refactordocker
perfsecurity
testscheduler
buildnotifications
cisma
revertdeps (for dependencies)
commonall (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

...