mirrors/electron
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions 1

summarize semantic commit requirements (#12665)

Browse source 
* summarize semantic commit requirements

* move semantic commit details into contributing docs

* keep those messages short
This commit is contained in:
Zeke Sikelianos 2018-05-02 07:47:26 -07:00 • committed by Charles Kerr
parent f1c7df8c28
commit 1957eb9429
2 changed files with 51 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

16
.github/config.yml vendored
View file

@ -12,14 +12,26 @@ newIssueWelcomeComment: |
newPRWelcomeComment: | newPRWelcomeComment: |
💖 Thanks for opening this pull request! 💖 💖 Thanks for opening this pull request! 💖
![typing cat](https://user-images.githubusercontent.com/2289/36400158-2c7c589e-1584-11e8-81c7-bd34fd3c392b.gif) We use
[semantic commit messages](https://github.com/electron/electron/blob/semantic-first-pr/docs/development/pull-requests.md#commit-message-guidelines)
to streamline the release process. Before your pull request can be merged, you
should **update your pull request title** to start with a semantic prefix,
OR prefix at least one of your commit messages.
Examples of commit messages with semantic prefixes:
- `fix: don't overwrite prevent_default if default wasn't prevented`
- `feat: add app.isPackaged() method`
- `docs: app.isDefaultProtocolClient is now available on Linux`
Things that will help get your PR across the finish line:
Here is a list of things that will help get it across the finish line:
- Follow the JavaScript, C++, and Python [coding style](https://github.com/electron/electron/blob/master/docs/development/coding-style.md). - Follow the JavaScript, C++, and Python [coding style](https://github.com/electron/electron/blob/master/docs/development/coding-style.md).
- Run `npm run lint` locally to catch formatting errors earlier. - Run `npm run lint` locally to catch formatting errors earlier.
- Document any user-facing changes you've made following the [documentation styleguide](https://github.com/electron/electron/blob/master/docs/styleguide.md). - Document any user-facing changes you've made following the [documentation styleguide](https://github.com/electron/electron/blob/master/docs/styleguide.md).
- Include tests when adding/changing behavior. - Include tests when adding/changing behavior.
- Include screenshots and animated GIFs whenever possible. - Include screenshots and animated GIFs whenever possible.
We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can. We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.
# Configuration for first-pr-merge - https://github.com/behaviorbot/first-pr-merge # Configuration for first-pr-merge - https://github.com/behaviorbot/first-pr-merge

46
docs/development/pull-requests.md
View file

@ -83,24 +83,52 @@ Note that multiple commits often get squashed when they are landed.
#### Commit message guidelines #### Commit message guidelines
A good commit message should describe what changed and why. A good commit message should describe what changed and why. The Electron project
uses [semantic commit messages](https://conventionalcommits.org/) to streamline
the release process.
Before a pull request can be merged, it should include at least one semantic
commit message, though it's not necessary for all commits in the pull request
to be semantic. Alternatively, you can **update your pull request title** to
start with a semantic prefix.
Examples of commit messages with semantic prefixes:
- `fix: don't overwrite prevent_default if default wasn't prevented`
- `feat: add app.isPackaged() method`
- `docs: app.isDefaultProtocolClient is now available on Linux`
Common prefixes:
- fix: A bug fix
- feat: A new feature
- docs: Documentation changes
- test: Adding missing tests or correcting existing tests
- build: Changes that affect the build system
- ci: Changes to our CI configuration files and scripts
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- style: Changes that do not affect the meaning of the code (linting)
Other things to keep in mind when writing a commit message:
1. The first line should: 1. The first line should:
- contain a short description of the change (preferably 50 characters or less, - contain a short description of the change (preferably 50 characters or less,
and no more than 72 characters) and no more than 72 characters)
- be entirely in lowercase with the exception of proper nouns, acronyms, and - be entirely in lowercase with the exception of proper nouns, acronyms, and
the words that refer to code, like function/variable names the words that refer to code, like function/variable names
Examples:
- `updated osx build documentation for new sdk`
- `fixed typos in atom_api_menu.h`
2. Keep the second line blank. 2. Keep the second line blank.
3. Wrap all other lines at 72 columns. 3. Wrap all other lines at 72 columns.
See [this article](https://chris.beams.io/posts/git-commit/) for more examples #### Breaking Changes
of how to write good git commit messages.
A commit that has the text `BREAKING CHANGE:` at the beginning of its optional
body or footer section introduces a breaking API change (correlating with Major
in semantic versioning). A breaking change can be part of commits of any type.
e.g., a `fix:`, `feat:` & `chore:` types would all be valid, in addition to any
other type.
See [conventionalcommits.org](https://conventionalcommits.org) for more details.
### Step 6: Rebase ### Step 6: Rebase