Page tree

Versions Compared

Key

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

...

  • Create or clone a repository
  • Start and manage a new branch
  • Make changes to a file and push them to GitHub as commits
  • Open and merge a pull request

Contribution Guidance - Top 4 things to do (or not do)

While this document and the others on our Wiki site provide a lot of great guidance to developers planning to make contributions to the project, we would ask that developers (and the maintainers/committers) of the project pay particular attention to the following "top 4" practices and adhere to them closely when working on project repositories.

1.    Commit subject line messages should explain the problem that the commit is solving in  50 characters or less.  “Fixing bug” or “adding comments” doesn’t explain the problem the commit is solving!.

2.    Provide a message body to the commit to provide more detail explanation.  When you do, keep lines in the body to 72 characters or less.

You can add a commit subject line and multiple message bodies like this:

git commit –s –m “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.”

3.    Commit your changes in logical chunks.  Make it easier for the community to review, comment on, and accept your contribution.  For example, create a separate commit for a big fix and an enhancement.

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.

EdgeX GitHub Getting Started

...

  • Be consistent. This is related to the workflow but also expands to things like commit messages, branch names and tags. Having a consistent style throughout the repository makes it easy to understand what is going on by looking at the log, a commit message etc.
  • Test before you push. Do not push half-done work.
  • Use annotated tags for marking releases or other important points in the history. Prefer lightweight tags for personal use, such as to bookmark commits for future reference.
  • Keep your repositories at a good shape by performing maintenance tasks occasionally:











1.    Commit subject line messages should explain the problem that the commit is solving in  50 characters or less.  “Fixing bug” or “adding comments” doesn’t explain the problem the commit is solving!.

2.    Provide a message body to the commit to provide more detail explanation.  When you do, keep lines in the body to 72 characters or less.

You can add a commit subject line and multiple message bodies like this:

git commit –s –m “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.”

3.    Commit your changes in logical chunks.  Make it easier for the community to review, comment on, and accept your contribution.  For example, create a separate commit for a big fix and an enhancement.

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.