mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2024-11-14 18:45:13 +01:00
style: Move to new UI
This commit is contained in:
Damiano Petrungaro
parent
f9af03c986
commit
87d94e3afe
4
.gitignore
vendored
4
.gitignore
vendored
@ -1,3 +1 @@
|
||||
_site
|
||||
.DS_Store
|
||||
vendor/
|
||||
public/
|
||||
|
||||
15
Dockerfile
Normal file
15
Dockerfile
Normal file
@ -0,0 +1,15 @@
|
||||
FROM node:alpine
|
||||
WORKDIR /src/
|
||||
COPY ./themes/conventional-commits /src/
|
||||
RUN npm rebuild node-sass
|
||||
RUN npm install
|
||||
RUN npm run build
|
||||
|
||||
FROM jguyomard/hugo-builder:latest
|
||||
COPY ./ /src/
|
||||
COPY --from=0 /src/ /src/themes/conventional-commits/
|
||||
RUN hugo
|
||||
|
||||
FROM nginx:stable
|
||||
COPY --from=1 /src/public/ /usr/share/nginx/html/
|
||||
EXPOSE 80
|
||||
7
Dockerfile.dev
Normal file
7
Dockerfile.dev
Normal file
@ -0,0 +1,7 @@
|
||||
FROM jguyomard/hugo-builder:latest
|
||||
FROM node:latest
|
||||
WORKDIR /src/
|
||||
COPY --from=0 /usr/local/bin/hugo /usr/local/bin/hugo
|
||||
COPY ./ /src/
|
||||
ENTRYPOINT make all-dev
|
||||
EXPOSE 1313
|
||||
41
Gemfile
41
Gemfile
@ -1,41 +0,0 @@
|
||||
source 'https://rubygems.org'
|
||||
|
||||
gem "jekyll", "3.4.3"
|
||||
gem "jekyll-sass-converter", "1.5.0"
|
||||
|
||||
# Converters
|
||||
gem "kramdown", "1.13.2"
|
||||
|
||||
# Misc
|
||||
gem "liquid", "3.0.6"
|
||||
gem "rouge", "1.11.1"
|
||||
|
||||
# Plugins
|
||||
gem "jekyll-redirect-from", "0.12.1"
|
||||
gem "jekyll-sitemap", "1.0.0"
|
||||
gem "jekyll-feed", "0.9.2"
|
||||
gem "jekyll-gist", "1.4.0"
|
||||
gem "jekyll-paginate", "1.1.0"
|
||||
gem "jekyll-coffeescript", "1.0.1"
|
||||
gem "jekyll-seo-tag", "2.1.0"
|
||||
gem "jekyll-avatar", "0.4.2"
|
||||
|
||||
# Plugins to match GitHub.com Markdown
|
||||
gem "jemoji", "0.8.0"
|
||||
gem "jekyll-mentions", "1.2.0"
|
||||
gem "jekyll-relative-links", "0.4.0"
|
||||
gem "jekyll-optional-front-matter", "0.1.2"
|
||||
gem "jekyll-readme-index", "0.1.0"
|
||||
gem "jekyll-default-layout", "0.1.4"
|
||||
gem "jekyll-titles-from-headings", "0.1.5"
|
||||
|
||||
# Pin listen because it's broken on 2.1 & that's what we recommend.
|
||||
# https://github.com/guard/listen/pull/371
|
||||
gem "listen", "3.0.6"
|
||||
|
||||
# Pin activesupport because 5.0 is broken on 2.1
|
||||
gem "activesupport", "4.2.7"
|
||||
gem "html-proofer"
|
||||
gem "rack-jekyll"
|
||||
gem 'rake'
|
||||
gem 'puma'
|
||||
167
Gemfile.lock
167
Gemfile.lock
@ -1,167 +0,0 @@
|
||||
GEM
|
||||
remote: https://rubygems.org/
|
||||
specs:
|
||||
activesupport (4.2.7)
|
||||
i18n (~> 0.7)
|
||||
json (~> 1.7, >= 1.7.7)
|
||||
minitest (~> 5.1)
|
||||
thread_safe (~> 0.3, >= 0.3.4)
|
||||
tzinfo (~> 1.1)
|
||||
addressable (2.5.2)
|
||||
public_suffix (>= 2.0.2, < 4.0)
|
||||
coffee-script (2.4.1)
|
||||
coffee-script-source
|
||||
execjs
|
||||
coffee-script-source (1.12.2)
|
||||
colorator (1.1.0)
|
||||
colorize (0.8.1)
|
||||
concurrent-ruby (1.0.5)
|
||||
ethon (0.11.0)
|
||||
ffi (>= 1.3.0)
|
||||
execjs (2.7.0)
|
||||
faraday (0.15.1)
|
||||
multipart-post (>= 1.2, < 3)
|
||||
ffi (1.9.23)
|
||||
forwardable-extended (2.6.0)
|
||||
gemoji (3.0.0)
|
||||
html-pipeline (2.8.0)
|
||||
activesupport (>= 2)
|
||||
nokogiri (>= 1.4)
|
||||
html-proofer (3.8.0)
|
||||
activesupport (>= 4.2, < 6.0)
|
||||
addressable (~> 2.3)
|
||||
colorize (~> 0.8)
|
||||
mercenary (~> 0.3.2)
|
||||
nokogiri (~> 1.8.1)
|
||||
parallel (~> 1.3)
|
||||
typhoeus (~> 1.3)
|
||||
yell (~> 2.0)
|
||||
i18n (0.9.5)
|
||||
concurrent-ruby (~> 1.0)
|
||||
jekyll (3.4.3)
|
||||
addressable (~> 2.4)
|
||||
colorator (~> 1.0)
|
||||
jekyll-sass-converter (~> 1.0)
|
||||
jekyll-watch (~> 1.1)
|
||||
kramdown (~> 1.3)
|
||||
liquid (~> 3.0)
|
||||
mercenary (~> 0.3.3)
|
||||
pathutil (~> 0.9)
|
||||
rouge (~> 1.7)
|
||||
safe_yaml (~> 1.0)
|
||||
jekyll-avatar (0.4.2)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-coffeescript (1.0.1)
|
||||
coffee-script (~> 2.2)
|
||||
jekyll-default-layout (0.1.4)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-feed (0.9.2)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-gist (1.4.0)
|
||||
octokit (~> 4.2)
|
||||
jekyll-mentions (1.2.0)
|
||||
activesupport (~> 4.0)
|
||||
html-pipeline (~> 2.3)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-optional-front-matter (0.1.2)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-paginate (1.1.0)
|
||||
jekyll-readme-index (0.1.0)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-redirect-from (0.12.1)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-relative-links (0.4.0)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-sass-converter (1.5.0)
|
||||
sass (~> 3.4)
|
||||
jekyll-seo-tag (2.1.0)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-sitemap (1.0.0)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-titles-from-headings (0.1.5)
|
||||
jekyll (~> 3.3)
|
||||
jekyll-watch (1.5.1)
|
||||
listen (~> 3.0)
|
||||
jemoji (0.8.0)
|
||||
activesupport (~> 4.0)
|
||||
gemoji (~> 3.0)
|
||||
html-pipeline (~> 2.2)
|
||||
jekyll (>= 3.0)
|
||||
json (1.8.6)
|
||||
kramdown (1.13.2)
|
||||
liquid (3.0.6)
|
||||
listen (3.0.6)
|
||||
rb-fsevent (>= 0.9.3)
|
||||
rb-inotify (>= 0.9.7)
|
||||
mercenary (0.3.6)
|
||||
mini_portile2 (2.3.0)
|
||||
minitest (5.11.3)
|
||||
multipart-post (2.0.0)
|
||||
nokogiri (1.8.2)
|
||||
mini_portile2 (~> 2.3.0)
|
||||
octokit (4.9.0)
|
||||
sawyer (~> 0.8.0, >= 0.5.3)
|
||||
parallel (1.12.1)
|
||||
pathutil (0.16.1)
|
||||
forwardable-extended (~> 2.6)
|
||||
public_suffix (3.0.2)
|
||||
puma (3.11.4)
|
||||
rack (1.6.10)
|
||||
rack-jekyll (0.5.0)
|
||||
jekyll (>= 1.3)
|
||||
listen (>= 1.3)
|
||||
rack (~> 1.5)
|
||||
rake (12.3.1)
|
||||
rb-fsevent (0.10.3)
|
||||
rb-inotify (0.9.10)
|
||||
ffi (>= 0.5.0, < 2)
|
||||
rouge (1.11.1)
|
||||
safe_yaml (1.0.4)
|
||||
sass (3.5.6)
|
||||
sass-listen (~> 4.0.0)
|
||||
sass-listen (4.0.0)
|
||||
rb-fsevent (~> 0.9, >= 0.9.4)
|
||||
rb-inotify (~> 0.9, >= 0.9.7)
|
||||
sawyer (0.8.1)
|
||||
addressable (>= 2.3.5, < 2.6)
|
||||
faraday (~> 0.8, < 1.0)
|
||||
thread_safe (0.3.6)
|
||||
typhoeus (1.3.0)
|
||||
ethon (>= 0.9.0)
|
||||
tzinfo (1.2.5)
|
||||
thread_safe (~> 0.1)
|
||||
yell (2.0.7)
|
||||
|
||||
PLATFORMS
|
||||
ruby
|
||||
|
||||
DEPENDENCIES
|
||||
activesupport (= 4.2.7)
|
||||
html-proofer
|
||||
jekyll (= 3.4.3)
|
||||
jekyll-avatar (= 0.4.2)
|
||||
jekyll-coffeescript (= 1.0.1)
|
||||
jekyll-default-layout (= 0.1.4)
|
||||
jekyll-feed (= 0.9.2)
|
||||
jekyll-gist (= 1.4.0)
|
||||
jekyll-mentions (= 1.2.0)
|
||||
jekyll-optional-front-matter (= 0.1.2)
|
||||
jekyll-paginate (= 1.1.0)
|
||||
jekyll-readme-index (= 0.1.0)
|
||||
jekyll-redirect-from (= 0.12.1)
|
||||
jekyll-relative-links (= 0.4.0)
|
||||
jekyll-sass-converter (= 1.5.0)
|
||||
jekyll-seo-tag (= 2.1.0)
|
||||
jekyll-sitemap (= 1.0.0)
|
||||
jekyll-titles-from-headings (= 0.1.5)
|
||||
jemoji (= 0.8.0)
|
||||
kramdown (= 1.13.2)
|
||||
liquid (= 3.0.6)
|
||||
listen (= 3.0.6)
|
||||
puma
|
||||
rack-jekyll
|
||||
rake
|
||||
rouge (= 1.11.1)
|
||||
|
||||
BUNDLED WITH
|
||||
1.16.1
|
||||
26
Makefile
Normal file
26
Makefile
Normal file
@ -0,0 +1,26 @@
|
||||
all: compile-assets compile-site
|
||||
all-dev: rebuild-node-sass compile-assets-dev serve-site-dev
|
||||
|
||||
compile-site:
|
||||
echo "Generating static website"
|
||||
hugo
|
||||
echo "Website generated"
|
||||
|
||||
serve-site-dev:
|
||||
echo "Serving website"
|
||||
hugo serve --bind=0.0.0.0
|
||||
|
||||
compile-assets:
|
||||
echo "Compiling assets"
|
||||
cd themes/conventional-commits && npm install && npm run build
|
||||
echo "Assets compiled"
|
||||
|
||||
compile-assets-dev:
|
||||
echo "Compiling assets"
|
||||
cd themes/conventional-commits && npm install && npm run start &
|
||||
|
||||
rebuild-node-sass:
|
||||
echo "Rebuilding node sass"
|
||||
cd themes/conventional-commits && npm rebuild node-sass
|
||||
echo "node sass rebuilt"
|
||||
|
||||
30
README.md
30
README.md
@ -6,9 +6,13 @@ This repo is the home of the Conventional Commits specification.
|
||||
|
||||
## Repo Layout
|
||||
|
||||
* `./index.md`: contains the current version of the specification.
|
||||
* `./spec`: contains past versions of the specification.
|
||||
* `./lang`: contains various translations of the specification.
|
||||
We use [HUGO](https://gohugo.io/) as static site generator, so we use the [directory structure](https://gohugo.io/getting-started/directory-structure/) HUGO proposes.
|
||||
|
||||
#### Our implementation
|
||||
|
||||
* `./content`: contains all the versions of the specification.
|
||||
* `./content/next/`: contains the version of the specification (where all the changes SHOULD be made).
|
||||
* `./content/**/index[.lang].md`: contains the content of the specification, if a language is specified it's a translation.
|
||||
|
||||
## Contributing
|
||||
|
||||
@ -18,17 +22,17 @@ to send a pull request.
|
||||
|
||||
### Adding a translation
|
||||
|
||||
1. Create a new folder in `lang/` with the appropriate language tag.
|
||||
2. Add a translated `index.md` to that folder.
|
||||
3. Add a translated `spec/vX.X.X.md` for the latest spec to that folder.
|
||||
4. Ensure all files have the appropriate `title` and `language` front matter (see others as an example).
|
||||
5. Add the language to the `_config.yml` file.
|
||||
1. Create a new file in `./content/version/index.{lang}.md` using the hugo command `hugo new {version}/index.{lang}.md`.
|
||||
1. Ensure all files have the appropriate fields required (see others as an example)..
|
||||
1. Add the language to the `config.yml` file (see others as an example).
|
||||
|
||||
### Running project locally
|
||||
|
||||
There's a docker-compose.yml file ready that will help you to check if the website looks good!
|
||||
To run it make sure you have [docker-compose installed](https://docs.docker.com/compose/install/#install-compose) on your machine and just use the command `docker-compose up` to make it run locally.
|
||||
|
||||
Once the website will be compiled, you can see the website visiting `http://localhost:1313`
|
||||
|
||||
## Badges!
|
||||
|
||||
Tell your users that you use the Conventional Commits specification:
|
||||
@ -37,7 +41,11 @@ Tell your users that you use the Conventional Commits specification:
|
||||
[](https://conventionalcommits.org)
|
||||
```
|
||||
|
||||
## Thank you semver.org
|
||||
## Thank you
|
||||
|
||||
We used [semver.org](https://github.com/mojombo/semver.org) as a blueprint for
|
||||
both the website and structure of this specification.
|
||||
To *[Lorenzo D'Ianni]*(https://github.com/lorenzodianni) for the great effort creating the CSS and the HTML for the new UI.
|
||||
|
||||
To [Netlify](https://www.netlify.com/) to host our project, giving us a lot of [amazing built in functionality](https://www.netlify.com/features/) for free.
|
||||
|
||||
To `semver.org`: we used [semver.org](https://github.com/mojombo/semver.org) as a blueprint for
|
||||
the structure of this specification and the first version of the website.
|
||||
5
Rakefile
5
Rakefile
@ -1,5 +0,0 @@
|
||||
namespace :assets do
|
||||
task :precompile do
|
||||
puts `bundle exec jekyll build`
|
||||
end
|
||||
end
|
||||
36
_config.yml
36
_config.yml
@ -1,36 +0,0 @@
|
||||
title: Conventional Commits
|
||||
descriptions: open-source maintainer, squash feature branches onto `master` and write a standardized commit message while doing so.
|
||||
|
||||
# Should be in the form of
|
||||
# <machine readable key>: <human readable label>
|
||||
languages:
|
||||
en: english
|
||||
pl: polish
|
||||
it: italian
|
||||
zh-Hans: 简体中文
|
||||
es: spanish
|
||||
|
||||
versions:
|
||||
- 1.0.0-beta
|
||||
- 1.0.0-beta.1
|
||||
- 1.0.0-beta.2
|
||||
|
||||
current_version: 1.0.0-beta.2
|
||||
|
||||
# Default author, for when none is set
|
||||
author: Benjamin Coe
|
||||
|
||||
gems:
|
||||
- jekyll-sitemap
|
||||
- jekyll-seo-tag
|
||||
- jekyll-redirect-from
|
||||
- kramdown
|
||||
|
||||
defaults:
|
||||
-
|
||||
scope:
|
||||
path: ""
|
||||
values:
|
||||
layout: "default"
|
||||
|
||||
exclude: ['docker-compose.yml', 'config.ru', 'Gemfile', 'Gemfile.lock', 'vendor', 'Procfile', 'Rakefile']
|
||||
@ -1,2 +0,0 @@
|
||||
github:
|
||||
url: ""
|
||||
@ -1,48 +0,0 @@
|
||||
<!doctype html>
|
||||
<html lang="{{ page.language | default: "en" }}" dir="{{ page.language_dir | default: "ltr" }}">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" href="/css/main.css">
|
||||
{% if page.custom_css %}
|
||||
<link rel="stylesheet" href="/css/{{ page.language }}.css">
|
||||
{% endif %}
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0"/>
|
||||
{% seo %}
|
||||
</head>
|
||||
<body>
|
||||
<a href="https://github.com/conventional-changelog/conventionalcommits.org"><img style="position: absolute; top: 0; right: 0; border: 0;" src="https://camo.githubusercontent.com/38ef81f8aca64bb9a64448d0d70f1308ef5341ab/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f72696768745f6461726b626c75655f3132313632312e706e67" alt="Fork me on GitHub" data-canonical-src="https://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png"></a>
|
||||
<ol class="nav lang" dir="ltr">
|
||||
{% assign sorted_languages = site.languages | sort %}
|
||||
{% for language in sorted_languages %}
|
||||
<li class="language language-{{ language[0] }}">
|
||||
<a rel="alternate" lang="{{ language[0] }}" hreflang="{{ language[0] }}"
|
||||
href="{{ language[0] | prepend: "/lang/" }}">
|
||||
{{ language[1] | smartify }} ({{ language[0] }})
|
||||
</a>
|
||||
</li>
|
||||
{% endfor %}
|
||||
</ol>
|
||||
<ol class="nav">
|
||||
{% assign language = page.language | default: "en" %}
|
||||
{% for version in site.versions %}
|
||||
{% if language == "en" %}
|
||||
{% assign expected = "spec/v" | append: version | append: ".md" %}
|
||||
{% else %}
|
||||
{% assign expected = "lang/" | append: language | append: "/spec/v" | append: version | append: ".md" %}
|
||||
{% endif %}
|
||||
{% assign found = site.pages | where: "path", expected | first %}
|
||||
{% if found %}
|
||||
<li class="version version-{{ version }}">
|
||||
<a href="{{ found.url }}">
|
||||
{{ version}}
|
||||
</a>
|
||||
</li>
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</ol>
|
||||
<div id="spec">
|
||||
{{ content }}
|
||||
</div>
|
||||
<script src="{{ site.github.url }}/js/anchorli.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
1
_redirects
Normal file
1
_redirects
Normal file
@ -0,0 +1 @@
|
||||
/ /en/v1.0.0-beta.2/
|
||||
3
archetypes/next.md
Normal file
3
archetypes/next.md
Normal file
@ -0,0 +1,3 @@
|
||||
---
|
||||
draft: true
|
||||
---
|
||||
3
archetypes/v1.0.0-beta.1.md
Normal file
3
archetypes/v1.0.0-beta.1.md
Normal file
@ -0,0 +1,3 @@
|
||||
---
|
||||
draft: false
|
||||
---
|
||||
3
archetypes/v1.0.0-beta.2.md
Normal file
3
archetypes/v1.0.0-beta.2.md
Normal file
@ -0,0 +1,3 @@
|
||||
---
|
||||
draft: false
|
||||
---
|
||||
3
archetypes/v1.0.0-beta.md
Normal file
3
archetypes/v1.0.0-beta.md
Normal file
@ -0,0 +1,3 @@
|
||||
---
|
||||
draft: false
|
||||
---
|
||||
102
config.yaml
Normal file
102
config.yaml
Normal file
@ -0,0 +1,102 @@
|
||||
baseURL: '/'
|
||||
languageCode: en-us
|
||||
theme: conventional-commits
|
||||
defaultContentLanguageInSubdir: true
|
||||
defaultContentLanguage: "en"
|
||||
|
||||
# Global parameters
|
||||
params:
|
||||
license:
|
||||
title: License
|
||||
action:
|
||||
label: Creative Commons - CC BY 3.0
|
||||
url: 'https://creativecommons.org/licenses/by/3.0/'
|
||||
|
||||
footer:
|
||||
logos:
|
||||
- name: github
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
|
||||
# Languages parameters
|
||||
languages:
|
||||
en:
|
||||
weight: 1
|
||||
languageName: "English"
|
||||
title: Conventional Commits
|
||||
description: A specification for adding human and machine readable meaning to commit messages
|
||||
actions:
|
||||
- label: Read the specs
|
||||
url: '#specification'
|
||||
- label: GitHub
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
versions:
|
||||
current: v1.0.0-beta.2
|
||||
list:
|
||||
- v1.0.0-beta.2
|
||||
- v1.0.0-beta.1
|
||||
- v1.0.0-beta
|
||||
|
||||
it:
|
||||
weight: 2
|
||||
languageName: "Italian"
|
||||
title: Commit Convenzionali
|
||||
description: Una specifica per aggiungere un significato leggibile da umani e macchine ai messaggi dei commit
|
||||
actions:
|
||||
- label: Leggi la specifica
|
||||
url: '#specifica'
|
||||
- label: GitHub
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
versions:
|
||||
current: v1.0.0-beta.2
|
||||
list:
|
||||
- v1.0.0-beta.2
|
||||
- v1.0.0-beta.1
|
||||
- v1.0.0-beta
|
||||
|
||||
pl:
|
||||
weight: 2
|
||||
languageName: "Polish"
|
||||
title: Konwencjonalne Commity
|
||||
description: Specyfikacja dodawania znaczenia czytelnego dla człowieka do commit komunikatów
|
||||
actions:
|
||||
- label: Przeczytaj specyfikację
|
||||
url: '#specyfikacja'
|
||||
- label: GitHub
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
versions:
|
||||
current: v1.0.0-beta.2
|
||||
list:
|
||||
- v1.0.0-beta.2
|
||||
- v1.0.0-beta.1
|
||||
- v1.0.0-beta
|
||||
zh:
|
||||
weight: 2
|
||||
languageName: "Chinese"
|
||||
title: 约定式提交
|
||||
description: 一种规范，用于添加人机可读的含义以提交消息
|
||||
actions:
|
||||
- label: 阅读规范
|
||||
url: '#约定式提交规范'
|
||||
- label: GitHub
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
versions:
|
||||
current: v1.0.0-beta.2
|
||||
list:
|
||||
- v1.0.0-beta.2
|
||||
- v1.0.0-beta.1
|
||||
- v1.0.0-beta
|
||||
|
||||
es:
|
||||
weight: 2
|
||||
languageName: "Spanish"
|
||||
title: Commits Convencionales
|
||||
description: Una especificación para agregar un significado legible por una máquina humana para commit mensajes
|
||||
actions:
|
||||
- label: Lee la especificación
|
||||
url: '#especificación'
|
||||
- label: GitHub
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
versions:
|
||||
current: v1.0.0-beta.2
|
||||
list:
|
||||
- v1.0.0-beta.2
|
||||
@ -1,14 +1,16 @@
|
||||
---
|
||||
title: Conventional Commits 1.0.0-beta.2
|
||||
redirect_from: /lang/en/
|
||||
draft: true
|
||||
---
|
||||
|
||||
# Conventional Commits 1.0.0-beta.2
|
||||
|
||||
## Summary
|
||||
|
||||
As a software developer, I want to squash feature branches onto `master` and write
|
||||
a standardized commit message while doing so.
|
||||
As a software developer, I want to create a readable commit history writing standardized commit messages to make easier and explicit what changes have been applied to a project.
|
||||
To accomplish it, the Conventional Commits specification proposes introducing a standardized lightweight
|
||||
convention on top of commit messages giving to you also the chance to automate processes.
|
||||
This convention dovetails with [SemVer](http://semver.org),
|
||||
asking software developers to describe in commit messages, features, fixes, and breaking changes that they make.
|
||||
|
||||
The commit message should be structured as follows:
|
||||
|
||||
@ -28,10 +30,10 @@ The commit contains the following structural elements, to communicate intent to
|
||||
consumers of your library:
|
||||
|
||||
1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
|
||||
2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in semantic versioning).
|
||||
3. **BREAKING CHANGE:** 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`](http://semver.org/#summary) in semantic versioning).
|
||||
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in semantic versioning).
|
||||
1. **BREAKING CHANGE:** 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`](http://semver.org/#summary) in semantic versioning).
|
||||
A BREAKING CHANGE can be part of commits of any _type_.
|
||||
4. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
|
||||
1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
|
||||
We also recommend `improvement` for commits that improve a current implementation without adding a new feature or fixing a bug.
|
||||
Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE).
|
||||
<br />
|
||||
@ -53,53 +55,34 @@ docs: correct spelling of CHANGELOG
|
||||
|
||||
### Commit message with scope
|
||||
```
|
||||
feat(lang): add polish language
|
||||
feat(lang): added polish language
|
||||
```
|
||||
|
||||
### Commit message for a fix using an (optional) issue number.
|
||||
```
|
||||
fix: correct minor typos in code
|
||||
fix: minor typos in code
|
||||
|
||||
see the issue for details on the typos fixed
|
||||
|
||||
fixes issue #12
|
||||
```
|
||||
|
||||
## Introduction
|
||||
|
||||
In software development, it's been my experience that bugs are most often introduced at the boundaries between applications.
|
||||
Unit testing works great for testing the interactions that a maintainer knows about, but do a poor job of capturing all the interesting, often unexpected, ways that a community puts a library to use.
|
||||
|
||||
Anyone who has upgraded to a new patch version of a dependency, only to watch their
|
||||
application start throwing a steady stream of 500 errors, knows how important
|
||||
a readable commit history (and [ideally a well maintained CHANGELOG](http://keepachangelog.com/en/0.3.0/)) is to the ensuing
|
||||
forensic process.
|
||||
|
||||
The Conventional Commits specification proposes introducing a standardized lightweight
|
||||
convention on top of commit messages. This convention dovetails with [SemVer](http://semver.org),
|
||||
asking software developers to describe in commit messages, features, fixes, and breaking
|
||||
changes that they make.
|
||||
|
||||
By introducing this convention, we create a common language that makes it easier to
|
||||
debug issues across project boundaries.
|
||||
|
||||
## Conventional Commits Specification
|
||||
## Specification
|
||||
|
||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by a colon and a space.
|
||||
2. The type `feat` MUST be used when a commit adds a new feature to your application or library.
|
||||
3. The type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
4. An optional scope MAY be provided after a type. A scope is a phrase describing a section of the codebase enclosed in parenthesis, e.g., `fix(parser):`
|
||||
5. A description MUST immediately follow the type/scope prefix.
|
||||
1. The type `feat` MUST be used when a commit adds a new feature to your application or library.
|
||||
1. The type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
1. An optional scope MAY be provided after a type. A scope is a phrase describing a section of the codebase enclosed in parenthesis, e.g., `fix(parser):`
|
||||
1. A description MUST immediately follow the type/scope prefix.
|
||||
The description is a short description of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
|
||||
7. A footer MAY be provided one blank line after the body (or after the description if body is missing).
|
||||
1. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
|
||||
1. A footer MAY be provided one blank line after the body (or after the description if body is missing).
|
||||
The footer SHOULD contain additional issue references about the code changes (such as the issues it fixes, e.g.,`Fixes #13`).
|
||||
8. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||
9. A description MUST be provided after the `BREAKING CHANGE: `, describing what has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. The footer MUST only contain `BREAKING CHANGE`, external links, issue references, and other meta-information.
|
||||
11. Types other than `feat` and `fix` MAY be used in your commit messages.
|
||||
1. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||
1. A description MUST be provided after the `BREAKING CHANGE: `, describing what has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
1. The footer MUST only contain `BREAKING CHANGE`, external links, issue references, and other meta-information.
|
||||
1. Types other than `feat` and `fix` MAY be used in your commit messages.
|
||||
|
||||
## Why Use Conventional Commits
|
||||
|
||||
@ -156,12 +139,6 @@ In a worst case scenario, it's not the end of the world if a commit lands that d
|
||||
No! If you use a squash based workflow on Git lead maintainers can cleanup the commit messages as they're merged—adding no workload to casual committers.
|
||||
A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.
|
||||
|
||||
### What writing form should I use?
|
||||
|
||||
We recommend writing a commit description and body using the [imperative](https://en.wikipedia.org/wiki/Imperative_mood) present tense writing form.
|
||||
|
||||
There are a significant number of examples of this writing form for commits [1](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)[2](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#subject)[3](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)[4](https://medium.com/@danielfeelfine/commit-verbs-101-why-i-like-to-use-this-and-why-you-should-also-like-it-d3ed2689ef70)[5](https://chris.beams.io/posts/git-commit/)
|
||||
|
||||
## About
|
||||
|
||||
The Conventional Commit specification is inspired by, and based heavily on, the [Angular Commit Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
|
||||
@ -184,7 +161,3 @@ The first draft of this specification has been written in collaboration with som
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_want your project on this list?_ [send a pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## License
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,5 @@
|
||||
---
|
||||
title: Commit Convenzionali 1.0.0-beta.1
|
||||
language: it
|
||||
draft: false
|
||||
---
|
||||
|
||||
# Commit Convenzionali 1.0.0-beta.1
|
||||
@ -28,8 +27,8 @@ Il commit contiene i seguenti elementi strutturali, allo scopo di comunicarne
|
||||
l'intento al consumatore della libreria:
|
||||
|
||||
1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
|
||||
2. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
1. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
1. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
Una _breaking change_ può essere parte di un commit di qualsiasi _tipo_.
|
||||
Es: I tipi `fix:`, `feat:` & `chore:` sono tutti validi.
|
||||
<br />
|
||||
@ -59,31 +58,31 @@ di descrivere nei messaggi dei commit qualsiasi feature, fix e breaking change l
|
||||
Introducendo questa convenzione, si crea un linguaggio comune che rende più semplice
|
||||
rimuovere errori tra progetti.
|
||||
|
||||
## Specifica Commit Convenzionali
|
||||
## Specifica
|
||||
|
||||
Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc.,
|
||||
seguito dai due punti ed uno spazio.
|
||||
2. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
|
||||
1. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
|
||||
all'applicazione o libreria.
|
||||
3. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
|
||||
4. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
|
||||
1. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
|
||||
1. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
|
||||
Un _contesto_ rappresenta una sezione dell'applicazione o libreria, il contentuo va racchiusa tra delle parentesi.
|
||||
Es: `fix(parser):`
|
||||
5. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
|
||||
1. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
|
||||
Per _descrizione_ si intende una breve spiegazione della pull request.
|
||||
Es: _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_.
|
||||
1. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_.
|
||||
Il _corpo_ DEVE inizare dopo una linea vuota dalla _descrizione_.
|
||||
7. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
|
||||
1. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
|
||||
Il _piè di pagina_ DOVREBBE contenere ulteriori informazioni riguardo la pull request (come le issue che risolve,
|
||||
Es: `fixes #13, #5`).
|
||||
8. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
|
||||
1. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
|
||||
Una _breaking change_ DEVE essere scritta in maiuscolo `BREAKING CHANGE`, seguita dai due punti ed uno spazio.
|
||||
9. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
|
||||
1. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
|
||||
Es: _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messagio.
|
||||
1. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messagio.
|
||||
|
||||
## Perchè utilizzare commit convenzionali
|
||||
|
||||
@ -159,7 +158,3 @@ La prima bozza di questa specifica è stata scritta in collaborazione con alcuni
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_vuoi aggingere il tuo progetto alla lista?_ [invia una pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licenza
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Conventional Commits 1.0.0-beta.1
|
||||
draft: false
|
||||
---
|
||||
|
||||
# Conventional Commits 1.0.0-beta.1
|
||||
@ -27,9 +27,9 @@ The commit contains the following structural elements, to communicate intent to
|
||||
consumers of your library:
|
||||
|
||||
1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
|
||||
2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
|
||||
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
|
||||
with [`MINOR`](http://semver.org/#summary) in semantic versioning).
|
||||
3. **BREAKING CHANGE:** 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`](http://semver.org/#summary) in semantic versioning). A breaking change can be
|
||||
1. **BREAKING CHANGE:** 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`](http://semver.org/#summary) 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_.
|
||||
|
||||
<br />
|
||||
@ -59,28 +59,28 @@ changes that they make.
|
||||
By introducing this convention, we create a common language that makes it easier to
|
||||
debug issues across project boundaries.
|
||||
|
||||
## Conventional Commits Specification
|
||||
## Specification
|
||||
|
||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
|
||||
followed by a colon and a space.
|
||||
2. the type `feat` MUST be used when a commit adds a new feature to your application
|
||||
1. the type `feat` MUST be used when a commit adds a new feature to your application
|
||||
or library.
|
||||
3. the type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
4. an optional scope MAY be provided after a type. A scope is a phrase describing
|
||||
1. the type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
1. an optional scope MAY be provided after a type. A scope is a phrase describing
|
||||
a section of the codebase enclosed in parenthesis, e.g., `fix(parser):`
|
||||
5. A description MUST immediately follow the type/scope prefix.
|
||||
1. A description MUST immediately follow the type/scope prefix.
|
||||
The description is a short description of the pull request, e.g.,
|
||||
_fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. A longer commit body MAY be provided after the short description. The body MUST
|
||||
1. A longer commit body MAY be provided after the short description. The body MUST
|
||||
begin one blank line after the description.
|
||||
7. A footer MAY be provided one blank line after the body. The footer SHOULD contain
|
||||
1. A footer MAY be provided one blank line after the body. The footer SHOULD contain
|
||||
additional meta-information about the pull-request (such as the issues it fixes, e.g., `fixes #13, #5`).
|
||||
8. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||
9. A description MUST be provided after the `BREAKING CHANGE: `, describing what
|
||||
1. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||
1. A description MUST be provided after the `BREAKING CHANGE: `, describing what
|
||||
has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. types other than `feat` and `fix` MAY be used in your commit messages.
|
||||
1. types other than `feat` and `fix` MAY be used in your commit messages.
|
||||
|
||||
## Why Use Conventional Commits
|
||||
|
||||
@ -156,7 +156,3 @@ folks contributing to:
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_want your project on this list?_ [send a pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## License
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,5 @@
|
||||
---
|
||||
title: Konwencjonalne Commity 1.0.0-beta.1
|
||||
language: pl
|
||||
draft: false
|
||||
---
|
||||
|
||||
# Konwencjonalne Commity 1.0.0-beta.1
|
||||
@ -28,8 +27,8 @@ Wiadomość zawiera następujące strukturalne elementy po to, aby zakomunikowa
|
||||
do użytkowników Twojej biblioteki:
|
||||
|
||||
1. **fix:** dostarczenie _typu_ `fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
|
||||
1. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
1. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
|
||||
|
||||
<br />
|
||||
Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
|
||||
@ -59,24 +58,24 @@ oraz jakie niekompatybilne wstecz zmiany wnoszą.
|
||||
Wprowadzając tę konwencję, tworzymy powszechny język, który pozwala na dużo łatwiejsze
|
||||
wyłapywanie błędów występujących na granicy projektu z jego zależnościami.
|
||||
|
||||
## Specyfikacja Konwencjonalnych Commitów
|
||||
## Specyfikacja
|
||||
|
||||
Następujące terminy “MUSI” (“MUST”), “NIE MOŻE” (“MUST NOT”), “WYMAGANY” (“REQUIRED”), “MA BYĆ” (“SHALL”), “NIE BĘDZIE” (“SHALL NOT”), “POWINIEN” (“SHOULD”), “NIE POWINIEN” (“SHOULD NOT”), “ZALECANY” (“RECOMMENDED”), “MOŻE” (“MAY”) oraz “OPCJONALNY” (“OPTIONAL”) pojawiające się w tym dokumencie rozumiane są zgodnie z ich opisem na stronie: [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Dostarczenie MUSI być poprzedzone typem, który składa się z rzeczownika, np. `feat`, `fix`, itp.,
|
||||
oraz następującymi bezpośrednio po nim dwukropka oraz spacji.
|
||||
2. Typ `feat` MUSI być użyty, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź biblioteki.
|
||||
3. Typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
4. Opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
5. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
1. Typ `feat` MUSI być użyty, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź biblioteki.
|
||||
1. Typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
1. Opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
1. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
Opis jest to krótka notka stanowiąca o treści dostarczenia, np.,
|
||||
_fix: problem podczas parsowania listy, kiedy string zawierał wiele spacji._
|
||||
6. Dłuższe ciało wiadomości MOŻE być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
7. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiązuje, np. `fixes #13, #5`.
|
||||
8. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadomości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
9. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
|
||||
1. Dłuższe ciało wiadomości MOŻE być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
1. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiązuje, np. `fixes #13, #5`.
|
||||
1. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadomości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
1. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
|
||||
np. _BREAKING CHANGE: zmienne środowiskowe mają teraz większy priorytet niż pliki konfiguracyjne._
|
||||
10. Typy inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
1. Typy inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
|
||||
## Dlaczego używać Konwencjonalnych Commitów
|
||||
|
||||
@ -154,8 +153,3 @@ pozwalających na parsowanie konwencjonalnych commitów z historii `git`owych do
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_chcesz, aby Twój projekt znajdował się na tej liście?_ [stwórz pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencja
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
---
|
||||
title: 约定式提交 1.0.0-beta.1
|
||||
language: zh-Hans
|
||||
draft: false
|
||||
---
|
||||
|
||||
# 约定式提交 1.0.0-beta.1
|
||||
@ -26,9 +25,9 @@ language: zh-Hans
|
||||
提交说明包含了下面的结构化元素，以向类库使用者表明其意图：
|
||||
|
||||
1. **fix:** _类型_ 为 `fix` 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 [`PATCH`](http://semver.org/#summary) 相对应）。
|
||||
2. **feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应）。
|
||||
3. **BREAKING CHANGE:** 在可选的正文或页脚的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性变更（这和语义化版本中的 [`MAJOR`](http://semver.org/#summary) 相对应）。破坏性变更可以是任意 _类型_ 提交的一部分。对于 `fix:`、`feat:` 和 `chore:`，乃至更多其它的 _类型_ 而言，它都是有效的。
|
||||
4. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
|
||||
1. **feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应）。
|
||||
1. **BREAKING CHANGE:** 在可选的正文或页脚的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性变更（这和语义化版本中的 [`MAJOR`](http://semver.org/#summary) 相对应）。破坏性变更可以是任意 _类型_ 提交的一部分。对于 `fix:`、`feat:` 和 `chore:`，乃至更多其它的 _类型_ 而言，它都是有效的。
|
||||
1. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
|
||||
|
||||
<br />
|
||||
可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 `feat(parser): add ability to parse arrays.`
|
||||
@ -48,15 +47,15 @@ language: zh-Hans
|
||||
本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
|
||||
|
||||
1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的名词组成，其后接冒号和空格。
|
||||
2. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
|
||||
3. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
|
||||
4. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
|
||||
5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. 在简短描述之后，**可以**编写更长的提交正文。正文**必须**起始于描述字段结束的一个空行后。
|
||||
7. 在正文结束的一个空行后，**可以**编写页脚。页脚**应当**包含额外的元信息（例如它所修复的 issue，类似 `fixse #13, #5` 等）。
|
||||
8. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
|
||||
9. 在 `BREAKING CHANGE: ` 之后**必须**提供描述，以描述对 API 的变更。例如 _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. 在提交说明中，**可以**使用 `feat` 和 `fix` 之外的类型。
|
||||
1. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
|
||||
1. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
|
||||
1. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
|
||||
1. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
|
||||
1. 在简短描述之后，**可以**编写更长的提交正文。正文**必须**起始于描述字段结束的一个空行后。
|
||||
1. 在正文结束的一个空行后，**可以**编写页脚。页脚**应当**包含额外的元信息（例如它所修复的 issue，类似 `fixse #13, #5` 等）。
|
||||
1. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
|
||||
1. 在 `BREAKING CHANGE: ` 之后**必须**提供描述，以描述对 API 的变更。例如 _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
1. 在提交说明中，**可以**使用 `feat` 和 `fix` 之外的类型。
|
||||
|
||||
## 为什么使用约定式提交
|
||||
|
||||
@ -127,7 +126,3 @@ language: zh-Hans
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_想让你的项目出现在上面吗？_[提交 pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls) 吧。
|
||||
|
||||
## 许可
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Commits Convencionales 1.0.0-beta.2
|
||||
language: es
|
||||
draft: false
|
||||
aliases: ["/es/"]
|
||||
---
|
||||
|
||||
# Commits Convencionales 1.0.0-beta.2
|
||||
@ -27,19 +27,19 @@ mensaje del commit debe estar estructurado de la siguiente forma:
|
||||
El commit contiene los siguientes elementos estructurales para comunicar la
|
||||
intención al consumidor de la librería:
|
||||
|
||||
1. **fix:** un commit de _tipo_ `fix` corrige un error en la base del código
|
||||
1. **fix:** un commit de _tipo_ `fix` corrige un error en la base del código
|
||||
(se correlaciona con [`PATCH`](http://semver.org/#summary) en el versionado
|
||||
semántico).
|
||||
2. **feat:** un commit de _tipo_ `feat` introduce nuevas características en la
|
||||
1. **feat:** un commit de _tipo_ `feat` introduce nuevas características en la
|
||||
base del código (se correlaciona con [`MINOR`](http://semver.org/#summary)
|
||||
en el versionado semántico).
|
||||
3. **BREAKING CHANGE:** un commit que contiene el texto `BREAKING CHANGE:` al
|
||||
1. **BREAKING CHANGE:** un commit que contiene el texto `BREAKING CHANGE:` al
|
||||
inicio de su cuerpo opcional o la sección de nota de pie introduce un cambio
|
||||
en el uso de la API (se correlaciona con [`MAJOR`](http://semver.org/#summary)
|
||||
en el versionado semántico). Un cambio en el uso de la API puede ser parte
|
||||
de commits de _tipo_. e.g., a `fix:`, `feat:` & `chore:` todos tipos
|
||||
válidos, adicional a cualquier otro _tipo_.
|
||||
4. Otros: _tipos_ de commits distintos a `fix:` y `feat:` están permitidos, por
|
||||
1. Otros: _tipos_ de commits distintos a `fix:` y `feat:` están permitidos, por
|
||||
ejemplo [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional)
|
||||
(basado en [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines))
|
||||
recomienda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` y
|
||||
@ -108,7 +108,7 @@ cambios que rompen el uso de la API que hagan.
|
||||
Al introducir esta convención, creamos un lenguaje común que permite depurar más
|
||||
fácilmente los problemas a través de las fronteras de un proyecto.
|
||||
|
||||
## Especificación de Commits Convencionales
|
||||
## Especificación
|
||||
|
||||
Las palabras “DEBE” (“MUST”), “NO DEBE” (“MUST NOT”), “REQUIERE” (“REQUIRED”),
|
||||
“DEBERÁ” (“SHALL”), “NO DEBERÁ” (“SHALL NOT”), “DEBERÍA” (“SHOULD”),
|
||||
@ -116,34 +116,34 @@ Las palabras “DEBE” (“MUST”), “NO DEBE” (“MUST NOT”), “REQUIER
|
||||
“OPCIONAL” (“OPTIONAL”) en este documento se deben interpretar como se describe
|
||||
en [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Los commits DEBEN iniciar con un tipo que consiste en un sustantivo `feat`, `fix`, etc.,
|
||||
1. Los commits DEBEN iniciar con un tipo que consiste en un sustantivo `feat`, `fix`, etc.,
|
||||
seguido de dos puntos y un espacio.
|
||||
2. El tipo `feat` DEBE ser usado cuando un commit agrega una nueva
|
||||
1. El tipo `feat` DEBE ser usado cuando un commit agrega una nueva
|
||||
característica a la aplicación o librería.
|
||||
3. El tipo `fix` DEBE ser usado cuando el commit representa una corrección a un
|
||||
1. El tipo `fix` DEBE ser usado cuando el commit representa una corrección a un
|
||||
error en el código de la aplicación.
|
||||
4. Se PUEDE añadir un ámbito opcional después del tipo. El ámbito es una frase
|
||||
1. Se PUEDE añadir un ámbito opcional después del tipo. El ámbito es una frase
|
||||
que describe una sección de la base del código encerrada en paréntesis,
|
||||
e.g., `fix(parser):`
|
||||
5. Una descripción DEBE ir inmediatamente después del tipo/ámbito inicial y es
|
||||
1. Una descripción DEBE ir inmediatamente después del tipo/ámbito inicial y es
|
||||
una descripción corta de los cambios realizados en el código, e.g.,
|
||||
_fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. Un cuerpo del commit más extenso PUEDE agregarse después de la descripción,
|
||||
1. Un cuerpo del commit más extenso PUEDE agregarse después de la descripción,
|
||||
dando información contextual adicional acerca de los cambios en el código.
|
||||
El cuerpo DEBE iniciar con una línea en blanco después de la descripción.
|
||||
7. Una nota de pie PUEDE agregarse tras una línea en blanco después del
|
||||
1. Una nota de pie PUEDE agregarse tras una línea en blanco después del
|
||||
cuerpo o después de la descripción en caso de que no se haya dado un cuerpo.
|
||||
La nota de pie DEBE contener referencias adicionales a los números de
|
||||
problemas registrados sobre el cambio del código (como el número de problema
|
||||
que corrige, e.g.,`Fixes #13`).
|
||||
8. Los cambios que rompen la API DEBEN ser indicados al inicio de la nota de
|
||||
1. Los cambios que rompen la API DEBEN ser indicados al inicio de la nota de
|
||||
pie o el cuerpo del commit. Un cambio que rompe la API DEBE contener el
|
||||
texto en mayúsculas `BREAKING CHANGE`, seguido de dos puntos y espacio.
|
||||
9. Una descripción se DEBE proveer después de `BREAKING CHANGE:`, describiendo
|
||||
1. Una descripción se DEBE proveer después de `BREAKING CHANGE:`, describiendo
|
||||
qué ha cambiado en la API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. La nota de pie DEBE contener solamente el texto `BREAKING CHANGE`, vínculos
|
||||
1. La nota de pie DEBE contener solamente el texto `BREAKING CHANGE`, vínculos
|
||||
externos, referencias a problemas u otra metainformación.
|
||||
11. Otros tipos distintos a `feat` y `fix` PUEDEN ser usados en los mensajes de
|
||||
1. Otros tipos distintos a `feat` y `fix` PUEDEN ser usados en los mensajes de
|
||||
los commits.
|
||||
|
||||
## ¿Por qué usar Commits Convencionales?
|
||||
@ -243,7 +243,3 @@ algunos de los colaboradores de:
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_¿Quiere ver su proyecto en esta lista?_ [haga un pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencia
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Commit Convenzionali 1.0.0-beta.2
|
||||
language: it
|
||||
draft: false
|
||||
aliases: ["/it/"]
|
||||
---
|
||||
|
||||
# Commit Convenzionali 1.0.0-beta.2
|
||||
@ -28,10 +28,10 @@ Il commit contiene i seguenti elementi strutturali, allo scopo di comunicarne
|
||||
l'intento al consumatore della libreria:
|
||||
|
||||
1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
|
||||
2. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
1. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
1. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
Una _breaking change_ può essere parte di un commit di qualsiasi _tipo_. Es: I tipi `fix:`, `feat:` & `chore:` sono tutti validi, cosí come qualsiasi altro _tipo_.
|
||||
4. Extra: sono ammessi ulteriori _tipi_ oltre `fix:` e`feat:`, per esempio [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (che si basa sulla [convenzione Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) raccomanda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
|
||||
1. Extra: sono ammessi ulteriori _tipi_ oltre `fix:` e`feat:`, per esempio [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (che si basa sulla [convenzione Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) raccomanda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
|
||||
Noi raccomandiamo anche `improvement` per commit che migliorano un'implementazione esistente senza aggiungere nuove funzionalità o risolvere un errore.
|
||||
Notare che questi _tipi_ non sono mantenuti da questa specifica, e non hanno un effetto sul versionamento semver (a meno che non introducano una _BREAKING CHANGE_, il quale NON è raccomandato).
|
||||
<br />
|
||||
@ -87,32 +87,32 @@ di descrivere nei messaggi dei commit qualsiasi feature, fix e breaking change l
|
||||
Introducendo questa convenzione, si crea un linguaggio comune che rende più semplice
|
||||
rimuovere errori tra progetti.
|
||||
|
||||
## Specifica Commit Convenzionali
|
||||
## Specifica
|
||||
|
||||
Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc.,
|
||||
seguito dai due punti ed uno spazio.
|
||||
2. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
|
||||
1. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
|
||||
all'applicazione o libreria.
|
||||
3. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
|
||||
4. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
|
||||
1. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
|
||||
1. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
|
||||
Un _contesto_ rappresenta una sezione dell'applicazione o libreria, il contentuo va racchiusa tra delle parentesi.
|
||||
Es: `fix(parser):`
|
||||
5. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
|
||||
1. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
|
||||
Per _descrizione_ si intende una breve spiegazione riguardo la modifica al codice.
|
||||
Es: _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_, aggiungendo ulteriori informazioni contestuali riguardo le modifiche apportate al codice.
|
||||
1. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_, aggiungendo ulteriori informazioni contestuali riguardo le modifiche apportate al codice.
|
||||
Il _corpo_ DEVE inizare dopo una linea vuota dalla _descrizione_.
|
||||
7. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
|
||||
1. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
|
||||
Il _piè di pagina_ DOVREBBE contenere ulteriori informazioni riguardo le modifiche apportate al codice (come le issue che risolve,
|
||||
Es: `fixes #13, #5`).
|
||||
8. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
|
||||
1. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
|
||||
Una _breaking change_ DEVE essere scritta in maiuscolo `BREAKING CHANGE`, seguita dai due punti ed uno spazio.
|
||||
9. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
|
||||
1. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
|
||||
Es: _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. Il _piè di pagina_ DEVE solo contentere `BREAKING CHANGE`, collegamenti esterni, riferimenti alle issueed ulteriori meta-informazioni.
|
||||
11. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messagio.
|
||||
1. Il _piè di pagina_ DEVE solo contentere `BREAKING CHANGE`, collegamenti esterni, riferimenti alle issueed ulteriori meta-informazioni.
|
||||
1. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messagio.
|
||||
|
||||
## Perchè utilizzare commit convenzionali
|
||||
|
||||
@ -188,7 +188,3 @@ La prima bozza di questa specifica è stata scritta in collaborazione con alcuni
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_vuoi aggingere il tuo progetto alla lista?_ [invia una pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licenza
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Conventional Commits 1.0.0-beta.2
|
||||
redirect_from: /lang/en/
|
||||
draft: false
|
||||
aliases: ["/en/"]
|
||||
---
|
||||
|
||||
# Conventional Commits 1.0.0-beta.2
|
||||
@ -28,11 +28,11 @@ The commit contains the following structural elements, to communicate intent to
|
||||
consumers of your library:
|
||||
|
||||
1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
|
||||
2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
|
||||
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
|
||||
with [`MINOR`](http://semver.org/#summary) in semantic versioning).
|
||||
3. **BREAKING CHANGE:** 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`](http://semver.org/#summary) in semantic versioning). A breaking change can be
|
||||
1. **BREAKING CHANGE:** 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`](http://semver.org/#summary) 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_.
|
||||
4. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others. We also recommend `improvement` for commits that improve a current implementation without adding a new feature or fixing a bug. Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE, which is NOT recommended).
|
||||
1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others. We also recommend `improvement` for commits that improve a current implementation without adding a new feature or fixing a bug. Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE, which is NOT recommended).
|
||||
<br />
|
||||
A scope may be provided to a commit's type, to provide additional contextual information and
|
||||
is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.
|
||||
@ -85,28 +85,28 @@ changes that they make.
|
||||
By introducing this convention, we create a common language that makes it easier to
|
||||
debug issues across project boundaries.
|
||||
|
||||
## Conventional Commits Specification
|
||||
## Specification
|
||||
|
||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
|
||||
followed by a colon and a space.
|
||||
2. The type `feat` MUST be used when a commit adds a new feature to your application
|
||||
1. The type `feat` MUST be used when a commit adds a new feature to your application
|
||||
or library.
|
||||
3. The type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
4. An optional scope MAY be provided after a type. A scope is a phrase describing
|
||||
1. The type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
1. An optional scope MAY be provided after a type. A scope is a phrase describing
|
||||
a section of the codebase enclosed in parenthesis, e.g., `fix(parser):`
|
||||
5. A description MUST immediately follow the type/scope prefix.
|
||||
1. A description MUST immediately follow the type/scope prefix.
|
||||
The description is a short description of the code changes, e.g.,
|
||||
_fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
|
||||
7. A footer MAY be provided one blank line after the body (or after the description if body is missing).
|
||||
1. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
|
||||
1. A footer MAY be provided one blank line after the body (or after the description if body is missing).
|
||||
The footer SHOULD contain additional issue references about the code changes (such as the issues it fixes, e.g.,`Fixes #13`).
|
||||
8. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||
9. A description MUST be provided after the `BREAKING CHANGE: `, describing what
|
||||
1. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||
1. A description MUST be provided after the `BREAKING CHANGE: `, describing what
|
||||
has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. The footer MUST only contain `BREAKING CHANGE`, external links, issue references, and other meta-information.
|
||||
11. Types other than `feat` and `fix` MAY be used in your commit messages.
|
||||
1. The footer MUST only contain `BREAKING CHANGE`, external links, issue references, and other meta-information.
|
||||
1. Types other than `feat` and `fix` MAY be used in your commit messages.
|
||||
|
||||
## Why Use Conventional Commits
|
||||
|
||||
@ -184,7 +184,3 @@ folks contributing to:
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_want your project on this list?_ [send a pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## License
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Konwencjonalne Commity 1.0.0-beta.2
|
||||
language: pl
|
||||
draft: false
|
||||
aliases: ["/pl/"]
|
||||
---
|
||||
|
||||
# Konwencjonalne Commity 1.0.0-beta.2
|
||||
@ -28,9 +28,9 @@ Wiadomość zawiera następujące strukturalne elementy po to, aby zakomunikowa
|
||||
do użytkowników Twojej biblioteki:
|
||||
|
||||
1. **fix:** dostarczenie _typu_ `fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
|
||||
4. Inne: commity _typu_ innego niż `fix:` oraz `feat:` są dozwolone, np. [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (bazowano na [konwencji Angulara](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) poleca `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, oraz inne. My polecamy także `improvement` dla dostarczeń, które ulepszają obecną implementację bez dodawania nowych funkcjonalności lub naprawy błędów. Zauważ, że te typy nie są obowiązkowe według specyfikacji konwencjonalnych commitów i nie mają wpływu na wersjonowanie (chyba, że zawierają BREAKING CHANGE, co NIE JEST rekomendowane).
|
||||
1. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
1. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
|
||||
1. Inne: commity _typu_ innego niż `fix:` oraz `feat:` są dozwolone, np. [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (bazowano na [konwencji Angulara](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) poleca `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, oraz inne. My polecamy także `improvement` dla dostarczeń, które ulepszają obecną implementację bez dodawania nowych funkcjonalności lub naprawy błędów. Zauważ, że te typy nie są obowiązkowe według specyfikacji konwencjonalnych commitów i nie mają wpływu na wersjonowanie (chyba, że zawierają BREAKING CHANGE, co NIE JEST rekomendowane).
|
||||
<br />
|
||||
Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
|
||||
Zawiera się on w nawiasach następujących bezpośrednio po typie, np. `feat(parser): dodano możliwość parsowania list`.
|
||||
@ -84,25 +84,25 @@ oraz jakie niekompatybilne wstecz zmiany wnoszą.
|
||||
Wprowadzając tę konwencję, tworzymy powszechny język, który pozwala na dużo łatwiejsze
|
||||
wyłapywanie błędów występujących na granicy projektu z jego zależnościami.
|
||||
|
||||
## Specyfikacja Konwencjonalnych Commitów
|
||||
## Specyfikacja
|
||||
|
||||
Następujące terminy “MUSI” (“MUST”), “NIE MOŻE” (“MUST NOT”), “WYMAGANY” (“REQUIRED”), “MA BYĆ” (“SHALL”), “NIE BĘDZIE” (“SHALL NOT”), “POWINIEN” (“SHOULD”), “NIE POWINIEN” (“SHOULD NOT”), “ZALECANY” (“RECOMMENDED”), “MOŻE” (“MAY”) oraz “OPCJONALNY” (“OPTIONAL”) pojawiające się w tym dokumencie rozumiane są zgodnie z ich opisem na stronie: [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Dostarczenie MUSI być poprzedzone typem, który składa się z rzeczownika, np. `feat`, `fix`, itp.,
|
||||
oraz następującymi bezpośrednio po nim dwukropka oraz spacji.
|
||||
2. Typ `feat` MUSI być użyty, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź biblioteki.
|
||||
3. Typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
4. Opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
5. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
1. Typ `feat` MUSI być użyty, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź biblioteki.
|
||||
1. Typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
1. Opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
1. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
Opis jest to krótka notka stanowiąca o treści dostarczenia, np.,
|
||||
_fix: problem podczas parsowania listy, kiedy string zawierał wiele spacji._
|
||||
6. Dłuższe ciało wiadomości MOŻE być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
7. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiązuje, np. `fixes #13, #5`.
|
||||
8. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadomości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
9. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
|
||||
1. Dłuższe ciało wiadomości MOŻE być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
1. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiązuje, np. `fixes #13, #5`.
|
||||
1. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadomości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
1. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
|
||||
np. _BREAKING CHANGE: zmienne środowiskowe mają teraz większy priorytet niż pliki konfiguracyjne._
|
||||
10. Stopka powinna zawierać tylko i wyłącznie `BREAKING CHANGE`, linki zewnętrzne, odnośniki do raportów błędów oraz inne meta-informacje.
|
||||
11. Typy inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
1. Stopka powinna zawierać tylko i wyłącznie `BREAKING CHANGE`, linki zewnętrzne, odnośniki do raportów błędów oraz inne meta-informacje.
|
||||
1. Typy inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
|
||||
## Dlaczego używać Konwencjonalnych Commitów
|
||||
|
||||
@ -181,7 +181,3 @@ pozwalających na parsowanie konwencjonalnych commitów z historii `git`owych do
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_chcesz, aby Twój projekt znajdował się na tej liście?_ [stwórz pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencja
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 约定式提交 1.0.0-beta.2
|
||||
language: zh-Hans
|
||||
draft: false
|
||||
aliases: ["/zh/"]
|
||||
---
|
||||
|
||||
# 约定式提交 1.0.0-beta.2
|
||||
@ -26,9 +26,9 @@ language: zh-Hans
|
||||
提交说明包含了下面的结构化元素，以向类库使用者表明其意图：
|
||||
|
||||
1. **fix:** _类型_ 为 `fix` 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 [`PATCH`](http://semver.org/#summary) 相对应）。
|
||||
2. **feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应）。
|
||||
3. **BREAKING CHANGE:** 在可选的正文或脚注的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性变更（这和语义化版本中的 [`MAJOR`](http://semver.org/#summary) 相对应）。破坏性变更可以是任意 _类型_ 提交的一部分。对于 `fix:`、`feat:` 和 `chore:`，乃至更多其它的 _类型_ 而言，它都是有效的。
|
||||
4. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
|
||||
1. **feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应）。
|
||||
1. **BREAKING CHANGE:** 在可选的正文或脚注的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性变更（这和语义化版本中的 [`MAJOR`](http://semver.org/#summary) 相对应）。破坏性变更可以是任意 _类型_ 提交的一部分。对于 `fix:`、`feat:` 和 `chore:`，乃至更多其它的 _类型_ 而言，它都是有效的。
|
||||
1. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
|
||||
|
||||
<br />
|
||||
可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 `feat(parser): adds ability to parse arrays.`
|
||||
@ -76,16 +76,16 @@ fixes issue #12
|
||||
本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
|
||||
|
||||
1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的名词组成，其后接冒号和空格。
|
||||
2. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
|
||||
3. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
|
||||
4. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
|
||||
5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对代码变更的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. 在简短描述之后，**可以**编写更长的提交正文，为代码变更提供额外的上下文信息。正文**必须**起始于描述字段结束的一个空行后。
|
||||
7. 在正文结束的一个空行后，**可以**编写脚注（如果正文缺失，可以编写在描述之后）。脚注**应当**为代码变更包含额外的 issue 引用信息（例如它所修复的 issue，类似 `Fixes #13` 等）。
|
||||
8. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
|
||||
9. 在 `BREAKING CHANGE: ` 之后**必须**提供描述，以描述对 API 的变更。例如 _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. 脚注**必须**只包含 `BREAKING CHANGE`、外部链接、issue 引用和其它元数据信息。
|
||||
11. 在提交说明中，**可以**使用 `feat` 和 `fix` 之外的类型。
|
||||
1. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
|
||||
1. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
|
||||
1. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
|
||||
1. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对代码变更的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
|
||||
1. 在简短描述之后，**可以**编写更长的提交正文，为代码变更提供额外的上下文信息。正文**必须**起始于描述字段结束的一个空行后。
|
||||
1. 在正文结束的一个空行后，**可以**编写脚注（如果正文缺失，可以编写在描述之后）。脚注**应当**为代码变更包含额外的 issue 引用信息（例如它所修复的 issue，类似 `Fixes #13` 等）。
|
||||
1. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
|
||||
1. 在 `BREAKING CHANGE: ` 之后**必须**提供描述，以描述对 API 的变更。例如 _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
1. 脚注**必须**只包含 `BREAKING CHANGE`、外部链接、issue 引用和其它元数据信息。
|
||||
1. 在提交说明中，**可以**使用 `feat` 和 `fix` 之外的类型。
|
||||
|
||||
## 为什么使用约定式提交
|
||||
|
||||
@ -156,7 +156,3 @@ fixes issue #12
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_想让你的项目出现在上面吗？_[提交 pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls) 吧。
|
||||
|
||||
## 许可
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,5 @@
|
||||
---
|
||||
title: Commit Convenzionali 1.0.0-beta
|
||||
language: it
|
||||
draft: false
|
||||
---
|
||||
|
||||
# Commit Convenzionali 1.0.0-beta
|
||||
@ -28,8 +27,8 @@ Il commit contiene i seguenti elementi strutturali, allo scopo di comunicarne
|
||||
l'intento al consumatore della libreria:
|
||||
|
||||
1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
|
||||
2. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
1. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
1. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
Una _breaking change_ può essere parte di entrambi i _tipi_ `fix:` w `feat:`.
|
||||
<br />
|
||||
Un _contesto_ potrebbe essere aggiunto al _tipo_ di commit, al fine di offrire ulteriori informazioni contestuali.
|
||||
@ -58,31 +57,31 @@ di descrivere nei messaggi dei commit qualsiasi feature, fix e breaking change l
|
||||
Introducendo questa convenzione, si crea un linguaggio comune che rende più semplice
|
||||
rimuovere errori tra progetti.
|
||||
|
||||
## Specifica Commit Convenzionali
|
||||
## Specifica
|
||||
|
||||
Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc.,
|
||||
seguito dai due punti ed uno spazio.
|
||||
2. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
|
||||
1. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
|
||||
all'applicazione o libreria.
|
||||
3. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
|
||||
4. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
|
||||
1. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
|
||||
1. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
|
||||
Un _contesto_ rappresenta una sezione dell'applicazione o libreria, il contentuo va racchiusa tra delle parentesi.
|
||||
Es: `fix(parser):`
|
||||
5. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
|
||||
1. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
|
||||
Per _descrizione_ si intende una breve spiegazione della pull request.
|
||||
Es: _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_.
|
||||
1. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_.
|
||||
Il _corpo_ DEVE inizare dopo una linea vuota dalla _descrizione_.
|
||||
7. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
|
||||
1. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
|
||||
Il _piè di pagina_ DOVREBBE contenere ulteriori informazioni riguardo la pull request (come le issue che risolve,
|
||||
Es: `fixes #13, #5`).
|
||||
8. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
|
||||
1. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
|
||||
Una _breaking change_ DEVE essere scritta in maiuscolo `BREAKING CHANGE`, seguita dai due punti ed uno spazio.
|
||||
9. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
|
||||
1. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
|
||||
Es: _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messagio.
|
||||
1. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messagio.
|
||||
|
||||
## Perchè utilizzare commit convenzionali
|
||||
|
||||
@ -158,7 +157,3 @@ La prima bozza di questa specifica è stata scritta in collaborazione con alcuni
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_vuoi aggingere il tuo progetto alla lista?_ [invia una pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licenza
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Conventional Commits 1.0.0-beta
|
||||
draft: false
|
||||
---
|
||||
|
||||
# Conventional Commits 1.0.0-beta
|
||||
@ -27,9 +27,9 @@ The commit contains the following structural elements, to communicate intent to
|
||||
consumers of your library:
|
||||
|
||||
1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
|
||||
2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
|
||||
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
|
||||
with [`MINOR`](http://semver.org/#summary) in semantic versioning).
|
||||
3. **BREAKING CHANGE:** 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`](http://semver.org/#summary) in semantic versioning). A breaking change can be
|
||||
1. **BREAKING CHANGE:** 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`](http://semver.org/#summary) in semantic versioning). A breaking change can be
|
||||
part of either a `fix:` or `feat:` _type_ commit.
|
||||
|
||||
<br />
|
||||
@ -59,28 +59,28 @@ changes that they make.
|
||||
By introducing this convention, we create a common language that makes it easier to
|
||||
debug issues across project boundaries.
|
||||
|
||||
## Conventional Commits Specification
|
||||
## Specification
|
||||
|
||||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
|
||||
followed by a colon and a space.
|
||||
2. the type `feat` MUST be used when a commit adds a new feature to your application
|
||||
1. the type `feat` MUST be used when a commit adds a new feature to your application
|
||||
or library.
|
||||
3. the type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
4. an optional scope MAY be provided after a type. A scope is a phrase describing
|
||||
1. the type `fix` MUST be used when a commit represents a bug fix for your application.
|
||||
1. an optional scope MAY be provided after a type. A scope is a phrase describing
|
||||
a section of the codebase enclosed in parenthesis, e.g., `fix(parser):`
|
||||
5. A description MUST immediately follow the type/scope prefix.
|
||||
1. A description MUST immediately follow the type/scope prefix.
|
||||
The description is a short description of the pull request, e.g.,
|
||||
_fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. A longer commit body MAY be provided after the short description. The body MUST
|
||||
1. A longer commit body MAY be provided after the short description. The body MUST
|
||||
begin one blank line after the description.
|
||||
7. A footer MAY be provided one blank line after the body. The footer SHOULD contain
|
||||
1. A footer MAY be provided one blank line after the body. The footer SHOULD contain
|
||||
additional meta-information about the pull-request (such as the issues it fixes, e.g., `fixes #13, #5`).
|
||||
8. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||
9. A description MUST be provided after the `BREAKING CHANGE: `, describing what
|
||||
1. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
|
||||
1. A description MUST be provided after the `BREAKING CHANGE: `, describing what
|
||||
has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. types other than `feat` and `fix` MAY be used in your commit messages.
|
||||
1. types other than `feat` and `fix` MAY be used in your commit messages.
|
||||
|
||||
## Why Use Conventional Commits
|
||||
|
||||
@ -157,6 +157,3 @@ folks contributing to:
|
||||
|
||||
_want your project on this list?_ [send a pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## License
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,5 @@
|
||||
---
|
||||
title: Konwencjonalne Commity 1.0.0-beta
|
||||
language: pl
|
||||
draft: false
|
||||
---
|
||||
|
||||
# Konwencjonalne Commity 1.0.0-beta
|
||||
@ -28,8 +27,8 @@ Wiadomość zawiera następujące strukturalne elementy po to, aby zakomunikowa
|
||||
do użytkowników Twojej biblioteki:
|
||||
|
||||
1. **fix:** dostarczenie _typu_ `fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian _typu_, `fix:` lub `feat:`.
|
||||
1. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
1. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian _typu_, `fix:` lub `feat:`.
|
||||
<br />
|
||||
Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
|
||||
Zawiera się on w nawiasach następujących bezpośrednio po typie, np. `feat(parser): dodano możliwość parsowania list`.
|
||||
@ -58,24 +57,24 @@ oraz jakie niekompatybilne wstecz zmiany wnoszą.
|
||||
Wprowadzając tę konwencję, tworzymy powszechny język, który pozwala na dużo łatwiejsze
|
||||
wyłapywanie błędów występujących na granicy projektu z jego zależnościami.
|
||||
|
||||
## Specyfikacja Konwencjonalnych Commitów
|
||||
## Specyfikacja
|
||||
|
||||
Następujące terminy “MUSI” (“MUST”), “NIE MOŻE” (“MUST NOT”), “WYMAGANY” (“REQUIRED”), “MA BYĆ” (“SHALL”), “NIE BĘDZIE” (“SHALL NOT”), “POWINIEN” (“SHOULD”), “NIE POWINIEN” (“SHOULD NOT”), “ZALECANY” (“RECOMMENDED”), “MOŻE” (“MAY”) oraz “OPCJONALNY” (“OPTIONAL”) pojawiające się w tym dokumencie rozumiane są zgodnie z ich opisem na stronie: [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Dostarczenie MUSI być poprzedzone typem, który składa się z rzeczownika, np. `feat`, `fix`, itp.,
|
||||
oraz następującymi bezpośrednio po nim dwukropka oraz spacji.
|
||||
2. Typ `feat` MUSI być użyt, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź bibliteki.
|
||||
3. Typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
4. Opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
5. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
1. Typ `feat` MUSI być użyt, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź bibliteki.
|
||||
1. Typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
1. Opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
1. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
Opis jest to krótka notka stanowiąca o treści dostarczenia, np.,
|
||||
_fix: problem podczas parsowania listy, kiedy string zawierał wiele spacji._
|
||||
6. Dłuższe ciało wiadomośći MOŻĘ być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
7. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiąznuje, np. `fixes #13, #5`.
|
||||
8. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadmości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
9. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
|
||||
1. Dłuższe ciało wiadomośći MOŻĘ być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
1. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiąznuje, np. `fixes #13, #5`.
|
||||
1. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadmości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
1. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
|
||||
np. _BREAKING CHANGE: zmienne środowiskowe mają teraz większy priorytet niż pliki konfiuguracyjne._
|
||||
10. Typy inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
1. Typy inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
|
||||
## Dlaczego używać Konwencjonalnych Commitów
|
||||
|
||||
@ -153,7 +152,3 @@ Pierwsza wersja tej specyfikacji została stworzona we współpracy z kilkoma ko
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_chcesz, aby Twój projekt znajdował się na tej liście?_ [stwórz pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencja
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,6 +1,5 @@
|
||||
---
|
||||
title: 约定式提交 1.0.0-beta
|
||||
language: zh-Hans
|
||||
draft: false
|
||||
---
|
||||
|
||||
# 约定式提交 1.0.0-beta
|
||||
@ -25,10 +24,10 @@ language: zh-Hans
|
||||
<br />
|
||||
提交说明包含了下面的结构化元素，以向类库使用者表明其意图：
|
||||
|
||||
1. **fix:** _类型_ 为 `fix` 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 [`PATCH`](http://semver.org/#summary) 相对应）。
|
||||
2. **feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应）。
|
||||
3. **BREAKING CHANGE:** 在可选的正文或页脚的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性变更（这和语义化版本中的 [`MAJOR`](http://semver.org/#summary) 相对应）。破坏性变更可以是 `fix:` 或 `feat:` _类型_ 提交的一部分。
|
||||
4. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
|
||||
1.**fix:** _类型_ 为 `fix` 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 [`PATCH`](http://semver.org/#summary) 相对应）。
|
||||
1.**feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应）。
|
||||
1.**BREAKING CHANGE:** 在可选的正文或页脚的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性变更（这和语义化版本中的 [`MAJOR`](http://semver.org/#summary) 相对应）。破坏性变更可以是 `fix:` 或 `feat:` _类型_ 提交的一部分。
|
||||
1.其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
|
||||
|
||||
<br />
|
||||
可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 `feat(parser): add ability to parse arrays.`
|
||||
@ -48,15 +47,15 @@ language: zh-Hans
|
||||
本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
|
||||
|
||||
1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的名词组成，其后接冒号和空格。
|
||||
2. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
|
||||
3. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
|
||||
4. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
|
||||
5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. 在简短描述之后，**可以**编写更长的提交正文。正文**必须**起始于描述字段结束的一个空行后。
|
||||
7. 在正文结束的一个空行后，**可以**编写页脚。页脚**应当**包含额外的元信息（例如它所修复的 issue，类似 `fixse #13, #5` 等）。
|
||||
8. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
|
||||
9. 在 `BREAKING CHANGE: ` 之后**必须**提供描述，以描述对 API 的变更。例如 _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. 在提交说明中，**可以**使用 `feat` 和 `fix` 之外的类型。
|
||||
1. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
|
||||
1. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
|
||||
1. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
|
||||
1. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
|
||||
1. 在简短描述之后，**可以**编写更长的提交正文。正文**必须**起始于描述字段结束的一个空行后。
|
||||
1. 在正文结束的一个空行后，**可以**编写页脚。页脚**应当**包含额外的元信息（例如它所修复的 issue，类似 `fixse #13, #5` 等）。
|
||||
1. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
|
||||
1. 在 `BREAKING CHANGE: ` 之后**必须**提供描述，以描述对 API 的变更。例如 _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
1. 在提交说明中，**可以**使用 `feat` 和 `fix` 之外的类型。
|
||||
|
||||
## 为什么使用约定式提交
|
||||
|
||||
@ -127,7 +126,3 @@ language: zh-Hans
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_想让你的项目出现在上面吗？_[提交 pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls) 吧。
|
||||
|
||||
## 许可
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,35 +0,0 @@
|
||||
/* -----------------------------------------------------------------------
|
||||
|
||||
|
||||
Blueprint CSS Framework 0.9
|
||||
http://blueprintcss.org
|
||||
|
||||
* Copyright (c) 2007-Present. See LICENSE for more info.
|
||||
* See README for instructions on how to use Blueprint.
|
||||
* For credits and origins, see AUTHORS.
|
||||
* This is a compressed file. See the sources in the 'src' directory.
|
||||
|
||||
----------------------------------------------------------------------- */
|
||||
|
||||
/* ie.css */
|
||||
body {text-align:center;}
|
||||
.container {text-align:left;}
|
||||
* html .column, * html div.span-1, * html div.span-2, * html div.span-3, * html div.span-4, * html div.span-5, * html div.span-6, * html div.span-7, * html div.span-8, * html div.span-9, * html div.span-10, * html div.span-11, * html div.span-12, * html div.span-13, * html div.span-14, * html div.span-15, * html div.span-16, * html div.span-17, * html div.span-18, * html div.span-19, * html div.span-20, * html div.span-21, * html div.span-22, * html div.span-23, * html div.span-24 {display:inline;overflow-x:hidden;}
|
||||
* html legend {margin:0px -8px 16px 0;padding:0;}
|
||||
sup {vertical-align:text-top;}
|
||||
sub {vertical-align:text-bottom;}
|
||||
html>body p code {*white-space:normal;}
|
||||
hr {margin:-8px auto 11px;}
|
||||
img {-ms-interpolation-mode:bicubic;}
|
||||
.clearfix, .container {display:inline-block;}
|
||||
* html .clearfix, * html .container {height:1%;}
|
||||
fieldset {padding-top:0;}
|
||||
textarea {overflow:auto;}
|
||||
input.text, input.title, textarea {background-color:#fff;border:1px solid #bbb;}
|
||||
input.text:focus, input.title:focus {border-color:#666;}
|
||||
input.text, input.title, textarea, select {margin:0.5em 0;}
|
||||
input.checkbox, input.radio {position:relative;top:.25em;}
|
||||
form.inline div, form.inline p {vertical-align:middle;}
|
||||
form.inline label {position:relative;top:-0.25em;}
|
||||
form.inline input.checkbox, form.inline input.radio, form.inline input.button, form.inline button {margin:0.5em 0;}
|
||||
button, input.button {position:relative;top:0.25em;}
|
||||
@ -1,29 +0,0 @@
|
||||
/* -----------------------------------------------------------------------
|
||||
|
||||
|
||||
Blueprint CSS Framework 0.9
|
||||
http://blueprintcss.org
|
||||
|
||||
* Copyright (c) 2007-Present. See LICENSE for more info.
|
||||
* See README for instructions on how to use Blueprint.
|
||||
* For credits and origins, see AUTHORS.
|
||||
* This is a compressed file. See the sources in the 'src' directory.
|
||||
|
||||
----------------------------------------------------------------------- */
|
||||
|
||||
/* print.css */
|
||||
body {line-height:1.5;font-family:"Helvetica Neue", Arial, Helvetica, sans-serif;color:#000;background:none;font-size:10pt;}
|
||||
.container {background:none;}
|
||||
hr {background:#ccc;color:#ccc;width:100%;height:2px;margin:2em 0;padding:0;border:none;}
|
||||
hr.space {background:#fff;color:#fff;visibility:hidden;}
|
||||
h1, h2, h3, h4, h5, h6 {font-family:"Helvetica Neue", Arial, "Lucida Grande", sans-serif;}
|
||||
code {font:.9em "Courier New", Monaco, Courier, monospace;}
|
||||
a img {border:none;}
|
||||
p img.top {margin-top:0;}
|
||||
blockquote {margin:1.5em;padding:1em;font-style:italic;font-size:.9em;}
|
||||
.small {font-size:.9em;}
|
||||
.large {font-size:1.1em;}
|
||||
.quiet {color:#999;}
|
||||
.hide {display:none;}
|
||||
a:link, a:visited {background:transparent;font-weight:700;text-decoration:underline;}
|
||||
a:link:after, a:visited:after {content:" (" attr(href) ")";font-size:90%;}
|
||||
@ -1,257 +0,0 @@
|
||||
/* -----------------------------------------------------------------------
|
||||
|
||||
|
||||
Blueprint CSS Framework 0.9
|
||||
http://blueprintcss.org
|
||||
|
||||
* Copyright (c) 2007-Present. See LICENSE for more info.
|
||||
* See README for instructions on how to use Blueprint.
|
||||
* For credits and origins, see AUTHORS.
|
||||
* This is a compressed file. See the sources in the 'src' directory.
|
||||
|
||||
----------------------------------------------------------------------- */
|
||||
|
||||
/* reset.css */
|
||||
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, code, del, dfn, em, img, q, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {margin:0;padding:0;border:0;font-weight:inherit;font-style:inherit;font-size:100%;font-family:inherit;vertical-align:baseline;}
|
||||
body {line-height:1.5;}
|
||||
table {border-collapse:separate;border-spacing:0;}
|
||||
caption, th, td {text-align:left;font-weight:normal;}
|
||||
table, td, th {vertical-align:middle;}
|
||||
blockquote:before, blockquote:after, q:before, q:after {content:"";}
|
||||
blockquote, q {quotes:"" "";}
|
||||
a img {border:none;}
|
||||
|
||||
/* typography.css */
|
||||
html {font-size:100.01%;}
|
||||
body {font-size:75%;color:#222;background:#fff;font-family:"Helvetica Neue", Arial, Helvetica, sans-serif;}
|
||||
h1, h2, h3, h4, h5, h6 {font-weight:normal;color:#111;}
|
||||
h1 {font-size:3em;line-height:1;margin-bottom:0.5em;}
|
||||
h2 {font-size:2em;margin-bottom:0.75em;}
|
||||
h3 {font-size:1.5em;line-height:1;margin-bottom:1em;}
|
||||
h4 {font-size:1.2em;line-height:1.25;margin-bottom:1.25em;}
|
||||
h5 {font-size:1em;font-weight:bold;margin-bottom:1.5em;}
|
||||
h6 {font-size:1em;font-weight:bold;}
|
||||
h1 img, h2 img, h3 img, h4 img, h5 img, h6 img {margin:0;}
|
||||
p {margin:0 0 1.5em;}
|
||||
p img.left {float:left;margin:1.5em 1.5em 1.5em 0;padding:0;}
|
||||
p img.right {float:right;margin:1.5em 0 1.5em 1.5em;}
|
||||
a:focus, a:hover {color:#000;}
|
||||
a {color:#009;text-decoration:underline;}
|
||||
blockquote {margin:1.5em;color:#666;font-style:italic;}
|
||||
strong {font-weight:bold;}
|
||||
em, dfn {font-style:italic;}
|
||||
dfn {font-weight:bold;}
|
||||
sup, sub {line-height:0;}
|
||||
abbr, acronym {border-bottom:1px dotted #666;}
|
||||
address {margin:0 0 1.5em;font-style:italic;}
|
||||
del {color:#666;}
|
||||
pre {margin:1.5em 0;white-space:pre;}
|
||||
pre, code, tt {font:1em 'andale mono', 'lucida console', monospace;line-height:1.5;}
|
||||
li ul, li ol {margin:0;}
|
||||
ul, ol {margin:0 1.5em 1.5em 0;padding-left:3.333em;}
|
||||
ul {list-style-type:disc;}
|
||||
ol {list-style-type:decimal;}
|
||||
dl {margin:0 0 1.5em 0;}
|
||||
dl dt {font-weight:bold;}
|
||||
dd {margin-left:1.5em;}
|
||||
table {margin-bottom:1.4em;width:100%;}
|
||||
th {font-weight:bold;}
|
||||
thead th {background:#c3d9ff;}
|
||||
th, td, caption {padding:4px 10px 4px 5px;}
|
||||
tr.even td {background:#e5ecf9;}
|
||||
tfoot {font-style:italic;}
|
||||
caption {background:#eee;}
|
||||
.small {font-size:.8em;margin-bottom:1.875em;line-height:1.875em;}
|
||||
.large {font-size:1.2em;line-height:2.5em;margin-bottom:1.25em;}
|
||||
.hide {display:none;}
|
||||
.quiet {color:#666;}
|
||||
.loud {color:#000;}
|
||||
.highlight {background:#ff0;}
|
||||
.added {background:#060;color:#fff;}
|
||||
.removed {background:#900;color:#fff;}
|
||||
.first {margin-left:0;padding-left:0;}
|
||||
.last {margin-right:0;padding-right:0;}
|
||||
.top {margin-top:0;padding-top:0;}
|
||||
.bottom {margin-bottom:0;padding-bottom:0;}
|
||||
|
||||
/* forms.css */
|
||||
label {font-weight:bold;}
|
||||
fieldset {padding:1.4em;margin:0 0 1.5em 0;border:1px solid #ccc;}
|
||||
legend {font-weight:bold;font-size:1.2em;}
|
||||
input[type=text], input[type=password], input.text, input.title, textarea, select {background-color:#fff;border:1px solid #bbb;}
|
||||
input[type=text]:focus, input[type=password]:focus, input.text:focus, input.title:focus, textarea:focus, select:focus {border-color:#666;}
|
||||
input[type=text], input[type=password], input.text, input.title, textarea, select {margin:0.5em 0;}
|
||||
input.text, input.title {width:300px;padding:5px;}
|
||||
input.title {font-size:1.5em;}
|
||||
textarea {width:390px;height:250px;padding:5px;}
|
||||
input[type=checkbox], input[type=radio], input.checkbox, input.radio {position:relative;top:.25em;}
|
||||
form.inline {line-height:3;}
|
||||
form.inline p {margin-bottom:0;}
|
||||
.error, .notice, .success {padding:.8em;margin-bottom:1em;border:2px solid #ddd;}
|
||||
.error {background:#FBE3E4;color:#8a1f11;border-color:#FBC2C4;}
|
||||
.notice {background:#FFF6BF;color:#514721;border-color:#FFD324;}
|
||||
.success {background:#E6EFC2;color:#264409;border-color:#C6D880;}
|
||||
.error a {color:#8a1f11;}
|
||||
.notice a {color:#514721;}
|
||||
.success a {color:#264409;}
|
||||
|
||||
/* grid.css */
|
||||
.container {width:950px;margin:0 auto;}
|
||||
.showgrid {background:url(src/grid.png);}
|
||||
.column, div.span-1, div.span-2, div.span-3, div.span-4, div.span-5, div.span-6, div.span-7, div.span-8, div.span-9, div.span-10, div.span-11, div.span-12, div.span-13, div.span-14, div.span-15, div.span-16, div.span-17, div.span-18, div.span-19, div.span-20, div.span-21, div.span-22, div.span-23, div.span-24 {float:left;margin-right:10px;}
|
||||
.last, div.last {margin-right:0;}
|
||||
.span-1 {width:30px;}
|
||||
.span-2 {width:70px;}
|
||||
.span-3 {width:110px;}
|
||||
.span-4 {width:150px;}
|
||||
.span-5 {width:190px;}
|
||||
.span-6 {width:230px;}
|
||||
.span-7 {width:270px;}
|
||||
.span-8 {width:310px;}
|
||||
.span-9 {width:350px;}
|
||||
.span-10 {width:390px;}
|
||||
.span-11 {width:430px;}
|
||||
.span-12 {width:470px;}
|
||||
.span-13 {width:510px;}
|
||||
.span-14 {width:550px;}
|
||||
.span-15 {width:590px;}
|
||||
.span-16 {width:630px;}
|
||||
.span-17 {width:670px;}
|
||||
.span-18 {width:710px;}
|
||||
.span-19 {width:750px;}
|
||||
.span-20 {width:790px;}
|
||||
.span-21 {width:830px;}
|
||||
.span-22 {width:870px;}
|
||||
.span-23 {width:910px;}
|
||||
.span-24, div.span-24 {width:950px;margin-right:0;}
|
||||
input.span-1, textarea.span-1, input.span-2, textarea.span-2, input.span-3, textarea.span-3, input.span-4, textarea.span-4, input.span-5, textarea.span-5, input.span-6, textarea.span-6, input.span-7, textarea.span-7, input.span-8, textarea.span-8, input.span-9, textarea.span-9, input.span-10, textarea.span-10, input.span-11, textarea.span-11, input.span-12, textarea.span-12, input.span-13, textarea.span-13, input.span-14, textarea.span-14, input.span-15, textarea.span-15, input.span-16, textarea.span-16, input.span-17, textarea.span-17, input.span-18, textarea.span-18, input.span-19, textarea.span-19, input.span-20, textarea.span-20, input.span-21, textarea.span-21, input.span-22, textarea.span-22, input.span-23, textarea.span-23, input.span-24, textarea.span-24 {border-left-width:1px!important;border-right-width:1px!important;padding-left:5px!important;padding-right:5px!important;}
|
||||
input.span-1, textarea.span-1 {width:18px!important;}
|
||||
input.span-2, textarea.span-2 {width:58px!important;}
|
||||
input.span-3, textarea.span-3 {width:98px!important;}
|
||||
input.span-4, textarea.span-4 {width:138px!important;}
|
||||
input.span-5, textarea.span-5 {width:178px!important;}
|
||||
input.span-6, textarea.span-6 {width:218px!important;}
|
||||
input.span-7, textarea.span-7 {width:258px!important;}
|
||||
input.span-8, textarea.span-8 {width:298px!important;}
|
||||
input.span-9, textarea.span-9 {width:338px!important;}
|
||||
input.span-10, textarea.span-10 {width:378px!important;}
|
||||
input.span-11, textarea.span-11 {width:418px!important;}
|
||||
input.span-12, textarea.span-12 {width:458px!important;}
|
||||
input.span-13, textarea.span-13 {width:498px!important;}
|
||||
input.span-14, textarea.span-14 {width:538px!important;}
|
||||
input.span-15, textarea.span-15 {width:578px!important;}
|
||||
input.span-16, textarea.span-16 {width:618px!important;}
|
||||
input.span-17, textarea.span-17 {width:658px!important;}
|
||||
input.span-18, textarea.span-18 {width:698px!important;}
|
||||
input.span-19, textarea.span-19 {width:738px!important;}
|
||||
input.span-20, textarea.span-20 {width:778px!important;}
|
||||
input.span-21, textarea.span-21 {width:818px!important;}
|
||||
input.span-22, textarea.span-22 {width:858px!important;}
|
||||
input.span-23, textarea.span-23 {width:898px!important;}
|
||||
input.span-24, textarea.span-24 {width:938px!important;}
|
||||
.append-1 {padding-right:40px;}
|
||||
.append-2 {padding-right:80px;}
|
||||
.append-3 {padding-right:120px;}
|
||||
.append-4 {padding-right:160px;}
|
||||
.append-5 {padding-right:200px;}
|
||||
.append-6 {padding-right:240px;}
|
||||
.append-7 {padding-right:280px;}
|
||||
.append-8 {padding-right:320px;}
|
||||
.append-9 {padding-right:360px;}
|
||||
.append-10 {padding-right:400px;}
|
||||
.append-11 {padding-right:440px;}
|
||||
.append-12 {padding-right:480px;}
|
||||
.append-13 {padding-right:520px;}
|
||||
.append-14 {padding-right:560px;}
|
||||
.append-15 {padding-right:600px;}
|
||||
.append-16 {padding-right:640px;}
|
||||
.append-17 {padding-right:680px;}
|
||||
.append-18 {padding-right:720px;}
|
||||
.append-19 {padding-right:760px;}
|
||||
.append-20 {padding-right:800px;}
|
||||
.append-21 {padding-right:840px;}
|
||||
.append-22 {padding-right:880px;}
|
||||
.append-23 {padding-right:920px;}
|
||||
.prepend-1 {padding-left:40px;}
|
||||
.prepend-2 {padding-left:80px;}
|
||||
.prepend-3 {padding-left:120px;}
|
||||
.prepend-4 {padding-left:160px;}
|
||||
.prepend-5 {padding-left:200px;}
|
||||
.prepend-6 {padding-left:240px;}
|
||||
.prepend-7 {padding-left:280px;}
|
||||
.prepend-8 {padding-left:320px;}
|
||||
.prepend-9 {padding-left:360px;}
|
||||
.prepend-10 {padding-left:400px;}
|
||||
.prepend-11 {padding-left:440px;}
|
||||
.prepend-12 {padding-left:480px;}
|
||||
.prepend-13 {padding-left:520px;}
|
||||
.prepend-14 {padding-left:560px;}
|
||||
.prepend-15 {padding-left:600px;}
|
||||
.prepend-16 {padding-left:640px;}
|
||||
.prepend-17 {padding-left:680px;}
|
||||
.prepend-18 {padding-left:720px;}
|
||||
.prepend-19 {padding-left:760px;}
|
||||
.prepend-20 {padding-left:800px;}
|
||||
.prepend-21 {padding-left:840px;}
|
||||
.prepend-22 {padding-left:880px;}
|
||||
.prepend-23 {padding-left:920px;}
|
||||
div.border {padding-right:4px;margin-right:5px;border-right:1px solid #eee;}
|
||||
div.colborder {padding-right:24px;margin-right:25px;border-right:1px solid #eee;}
|
||||
.pull-1 {margin-left:-40px;}
|
||||
.pull-2 {margin-left:-80px;}
|
||||
.pull-3 {margin-left:-120px;}
|
||||
.pull-4 {margin-left:-160px;}
|
||||
.pull-5 {margin-left:-200px;}
|
||||
.pull-6 {margin-left:-240px;}
|
||||
.pull-7 {margin-left:-280px;}
|
||||
.pull-8 {margin-left:-320px;}
|
||||
.pull-9 {margin-left:-360px;}
|
||||
.pull-10 {margin-left:-400px;}
|
||||
.pull-11 {margin-left:-440px;}
|
||||
.pull-12 {margin-left:-480px;}
|
||||
.pull-13 {margin-left:-520px;}
|
||||
.pull-14 {margin-left:-560px;}
|
||||
.pull-15 {margin-left:-600px;}
|
||||
.pull-16 {margin-left:-640px;}
|
||||
.pull-17 {margin-left:-680px;}
|
||||
.pull-18 {margin-left:-720px;}
|
||||
.pull-19 {margin-left:-760px;}
|
||||
.pull-20 {margin-left:-800px;}
|
||||
.pull-21 {margin-left:-840px;}
|
||||
.pull-22 {margin-left:-880px;}
|
||||
.pull-23 {margin-left:-920px;}
|
||||
.pull-24 {margin-left:-960px;}
|
||||
.pull-1, .pull-2, .pull-3, .pull-4, .pull-5, .pull-6, .pull-7, .pull-8, .pull-9, .pull-10, .pull-11, .pull-12, .pull-13, .pull-14, .pull-15, .pull-16, .pull-17, .pull-18, .pull-19, .pull-20, .pull-21, .pull-22, .pull-23, .pull-24 {float:left;position:relative;}
|
||||
.push-1 {margin:0 -40px 1.5em 40px;}
|
||||
.push-2 {margin:0 -80px 1.5em 80px;}
|
||||
.push-3 {margin:0 -120px 1.5em 120px;}
|
||||
.push-4 {margin:0 -160px 1.5em 160px;}
|
||||
.push-5 {margin:0 -200px 1.5em 200px;}
|
||||
.push-6 {margin:0 -240px 1.5em 240px;}
|
||||
.push-7 {margin:0 -280px 1.5em 280px;}
|
||||
.push-8 {margin:0 -320px 1.5em 320px;}
|
||||
.push-9 {margin:0 -360px 1.5em 360px;}
|
||||
.push-10 {margin:0 -400px 1.5em 400px;}
|
||||
.push-11 {margin:0 -440px 1.5em 440px;}
|
||||
.push-12 {margin:0 -480px 1.5em 480px;}
|
||||
.push-13 {margin:0 -520px 1.5em 520px;}
|
||||
.push-14 {margin:0 -560px 1.5em 560px;}
|
||||
.push-15 {margin:0 -600px 1.5em 600px;}
|
||||
.push-16 {margin:0 -640px 1.5em 640px;}
|
||||
.push-17 {margin:0 -680px 1.5em 680px;}
|
||||
.push-18 {margin:0 -720px 1.5em 720px;}
|
||||
.push-19 {margin:0 -760px 1.5em 760px;}
|
||||
.push-20 {margin:0 -800px 1.5em 800px;}
|
||||
.push-21 {margin:0 -840px 1.5em 840px;}
|
||||
.push-22 {margin:0 -880px 1.5em 880px;}
|
||||
.push-23 {margin:0 -920px 1.5em 920px;}
|
||||
.push-24 {margin:0 -960px 1.5em 960px;}
|
||||
.push-1, .push-2, .push-3, .push-4, .push-5, .push-6, .push-7, .push-8, .push-9, .push-10, .push-11, .push-12, .push-13, .push-14, .push-15, .push-16, .push-17, .push-18, .push-19, .push-20, .push-21, .push-22, .push-23, .push-24 {float:right;position:relative;}
|
||||
.prepend-top {margin-top:1.5em;}
|
||||
.append-bottom {margin-bottom:1.5em;}
|
||||
.box {padding:1.5em;margin-bottom:1.5em;background:#E5ECF9;}
|
||||
hr {background:#ddd;color:#ddd;clear:both;float:none;width:100%;height:.1em;margin:0 0 1.45em;border:none;}
|
||||
hr.space {background:#fff;color:#fff;visibility:hidden;}
|
||||
.clearfix:after, .container:after {content:"\0020";display:block;height:0;clear:both;visibility:hidden;overflow:hidden;}
|
||||
.clearfix, .container {display:block;}
|
||||
.clear {clear:both;}
|
||||
@ -1,30 +0,0 @@
|
||||
@import url(http://fonts.googleapis.com/earlyaccess/droidarabickufi.css);
|
||||
@import url(http://fonts.googleapis.com/earlyaccess/droidarabicnaskh.css);
|
||||
@import url(http://fonts.googleapis.com/earlyaccess/thabit.css);
|
||||
|
||||
|
||||
html {
|
||||
font-family: 'Droid Arabic Naskh', tahoma, Helvetica, Arial, sans-serif;
|
||||
line-height: 1.8em;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
font-family: 'Droid Arabic Kufi', Arial, sans-serif;
|
||||
}
|
||||
|
||||
h3 {
|
||||
text-align: right;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
code {
|
||||
direction: ltr !important;
|
||||
background-color: #ecf0f1;
|
||||
padding: 5px;
|
||||
font-family: 'Thabit', 'Courier New', serif;
|
||||
font-size: 18px;
|
||||
}
|
||||
|
||||
p {
|
||||
text-align: justify;
|
||||
}
|
||||
@ -1,3 +0,0 @@
|
||||
html { font-size: 16px; }
|
||||
|
||||
h1, h2, h3 { font-family: "Microsoft YaHei", "Heiti TC", "Heiti SC"; }
|
||||
@ -1,3 +0,0 @@
|
||||
html { font-size: 16px; }
|
||||
|
||||
h1, h2, h3 { font-family: "Microsoft JhengHei", "Microsoft YaHei", "Heiti TC", "Heiti SC"; }
|
||||
95
css/main.css
95
css/main.css
@ -1,95 +0,0 @@
|
||||
/*
|
||||
CSS for semver.org
|
||||
@author Mathias Bynens
|
||||
@link http://mathiasbynens.be/
|
||||
*/
|
||||
|
||||
h1, h2, ol { margin: 0; padding: 0; }
|
||||
|
||||
html { font: 14.4px/1.5 Helvetica, Arial, sans-serif; }
|
||||
body { margin: 0 auto; padding: 0 10%; max-width: 710px; }
|
||||
|
||||
@-ms-viewport { width: device-width; }
|
||||
html { -webkit-text-size-adjust: 100%; }
|
||||
|
||||
h1, h2, h3 { text-align: center; font-weight: normal; }
|
||||
h1 { font-size: 43px; margin: 1.1em 0 .7em; }
|
||||
h2 { margin: 2.1em 0 .7em; font-size: 24px; }
|
||||
h3 { text-align: left; font-size: 15.8px; margin-bottom: .6em; }
|
||||
|
||||
a { color: #009; }
|
||||
a:hover, a:focus { color: #000; }
|
||||
ol { padding-left: 1.5em; }
|
||||
p { margin: 0 0 1em; }
|
||||
|
||||
@media print {
|
||||
body { width: 100%; }
|
||||
h1, h2, h3 { font-weight: bold; }
|
||||
a:after { content: ' <' attr(href) '>'; font-size: 90%; }
|
||||
}
|
||||
|
||||
/* Nav */
|
||||
|
||||
ol.nav {
|
||||
background-color: #333;
|
||||
list-style-type: none;
|
||||
margin: 0;
|
||||
padding: 10px;
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
ol.nav li {
|
||||
display: inline;
|
||||
font-weight: bold;
|
||||
margin-right: 20px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
||||
ol.nav li a {
|
||||
color: white;
|
||||
}
|
||||
|
||||
ol.lang {
|
||||
background-color: white;
|
||||
}
|
||||
|
||||
ol.lang li a {
|
||||
color: black;
|
||||
}
|
||||
|
||||
/* Anchor Link styling */
|
||||
|
||||
#spec a.anchor-link {
|
||||
opacity: 0;
|
||||
/* Got this background image from an AnchorJs example http://bryanbraun.github.io/anchorjs/ */
|
||||
background: url("data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjxzdmcgd2lkdGg9IjIwcHgiIGhlaWdodD0iMTBweCIgdmlld0JveD0iMCAwIDIwIDEwIiB2ZXJzaW9uPSIxLjEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiPgogICAgPGRlZnM+PC9kZWZzPgogICAgPGcgaWQ9IlBhZ2UtMSIgc3Ryb2tlPSJub25lIiBzdHJva2Utd2lkdGg9IjEiIGZpbGw9Im5vbmUiIGZpbGwtcnVsZT0iZXZlbm9kZCI+CiAgICAgICAgPGcgaWQ9ImxpbmsiIGZpbGw9IiNGRjUyMzEiPgogICAgICAgICAgICA8cGF0aCBkPSJNMTUsMCBMMTIuMzA0Njg3NSwwIEMxMy4yNDIxODc1LDAuNjI1IDE0LjEyMTA5MzgsMS43MzgyODEyNSAxNC4zOTQ1MzEyLDIuNSBMMTQuOTgwNDY4OCwyLjUgQzE2LjI1LDIuNSAxNy40ODA0Njg4LDMuNzUgMTcuNDgwNDY4OCw1IEMxNy40ODA0Njg4LDYuMjUgMTYuMjEwOTM3NSw3LjUgMTQuOTgwNDY4OCw3LjUgTDExLjIzMDQ2ODgsNy41IEMxMCw3LjUgOC43MzA0Njg3NSw2LjI1IDguNzMwNDY4NzUsNSBDOC43MzA0Njg3NSw0LjU1MDc4MTI1IDguODY3MTg3NSw0LjEyMTA5Mzc1IDkuMDgyMDMxMjUsMy43NSBMNi40MDYyNSwzLjc1IEM2LjMwODU5Mzc1LDQuMTYwMTU2MjUgNi4yNSw0LjU3MDMxMjUgNi4yNSw1IEM2LjI1LDcuNSA4LjczMDQ2ODc1LDEwIDExLjIzMDQ2ODgsMTAgTDE1LDEwIEMxNy41LDEwIDIwLDcuNSAyMCw1IEMyMCwyLjUgMTcuNSwwIDE1LDAgTDE1LDAgWiBNNS42MDU0Njg3NSw3LjUgTDUuMDE5NTMxMjUsNy41IEMzLjc1LDcuNSAyLjUxOTUzMTI1LDYuMjUgMi41MTk1MzEyNSw1IEMyLjUxOTUzMTI1LDMuNzUgMy43ODkwNjI1LDIuNSA1LjAxOTUzMTI1LDIuNSBMOC43Njk1MzEyNSwyLjUgQzEwLDIuNSAxMS4yNjk1MzEyLDMuNzUgMTEuMjY5NTMxMiw1IEMxMS4yNjk1MzEyLDUuNDQ5MjE4NzUgMTEuMTMyODEyNSw1Ljg3ODkwNjI1IDEwLjkxNzk2ODgsNi4yNSBMMTMuNTkzNzUsNi4yNSBDMTMuNjkxNDA2Miw1LjgzOTg0Mzc1IDEzLjc1LDUuNDI5Njg3NSAxMy43NSw1IEMxMy43NSwyLjUgMTEuMjY5NTMxMiwwIDguNzY5NTMxMjUsMCBMNSwwIEMyLjUsMCAwLDIuNSAwLDUgQzAsNy41IDIuNSwxMCA1LDEwIEw3LjY5NTMxMjUsMTAgQzYuNzU3ODEyNSw5LjM3NSA1Ljg3ODkwNjI1LDguMjYxNzE4NzUgNS42MDU0Njg3NSw3LjUgTDUuNjA1NDY4NzUsNy41IFoiIGlkPSJTaGFwZSI+PC9wYXRoPgogICAgICAgIDwvZz4KICAgIDwvZz4KPC9zdmc+") no-repeat;
|
||||
position: absolute;
|
||||
margin-top: 0.5em;
|
||||
margin-left: -1em;
|
||||
padding-right: 0.5em;
|
||||
height: 16px;
|
||||
width: 20px;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
#spec h1 a.anchor-link {
|
||||
margin-left: -0.6em;
|
||||
}
|
||||
|
||||
#spec h3 a.anchor-link {
|
||||
margin-left: -1.5em;
|
||||
margin-top: 0.4em;
|
||||
}
|
||||
|
||||
#spec li a.anchor-link {
|
||||
margin-top: 0.4em;
|
||||
margin-left: -3em;
|
||||
}
|
||||
|
||||
#spec [id] {
|
||||
position: relative;
|
||||
}
|
||||
|
||||
#spec [id]:hover > .anchor-link, .anchor-link:focus {
|
||||
opacity: 1;
|
||||
}
|
||||
@ -1,60 +0,0 @@
|
||||
html {
|
||||
font-size: 120%;
|
||||
line-height: 1.75em;
|
||||
}
|
||||
|
||||
.container {
|
||||
margin-top: 2em;
|
||||
margin-bottom: 2em;
|
||||
width: 710px;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
margin-top: 1em;
|
||||
margin-bottom: .75em;
|
||||
line-height: 1.5em;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 300%;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
h2 {
|
||||
margin-top: 2em;
|
||||
font-size: 170%;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 110%;
|
||||
}
|
||||
|
||||
p {
|
||||
margin: 0 0 1em;
|
||||
}
|
||||
|
||||
pre {
|
||||
margin: 1em 0;
|
||||
border: 1px solid #ddd;
|
||||
padding: .25em .25em;
|
||||
background-color: #eef;
|
||||
}
|
||||
|
||||
code {
|
||||
border: 1px solid #ddd;
|
||||
padding: 0 .2em;
|
||||
background-color: #eef;
|
||||
}
|
||||
|
||||
pre code {
|
||||
border: none;
|
||||
}
|
||||
|
||||
ol {
|
||||
padding-left: 1.5em;
|
||||
}
|
||||
|
||||
td {
|
||||
padding: .25em 1em .25em 0;
|
||||
}
|
||||
@ -1,60 +0,0 @@
|
||||
.highlight { background: #ffffff; }
|
||||
.highlight .c { color: #999988; font-style: italic } /* Comment */
|
||||
.highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */
|
||||
.highlight .k { font-weight: bold } /* Keyword */
|
||||
.highlight .o { font-weight: bold } /* Operator */
|
||||
.highlight .cm { color: #999988; font-style: italic } /* Comment.Multiline */
|
||||
.highlight .cp { color: #999999; font-weight: bold } /* Comment.Preproc */
|
||||
.highlight .c1 { color: #999988; font-style: italic } /* Comment.Single */
|
||||
.highlight .cs { color: #999999; font-weight: bold; font-style: italic } /* Comment.Special */
|
||||
.highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */
|
||||
.highlight .gd .x { color: #000000; background-color: #ffaaaa } /* Generic.Deleted.Specific */
|
||||
.highlight .ge { font-style: italic } /* Generic.Emph */
|
||||
.highlight .gr { color: #aa0000 } /* Generic.Error */
|
||||
.highlight .gh { color: #999999 } /* Generic.Heading */
|
||||
.highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */
|
||||
.highlight .gi .x { color: #000000; background-color: #aaffaa } /* Generic.Inserted.Specific */
|
||||
.highlight .go { color: #888888 } /* Generic.Output */
|
||||
.highlight .gp { color: #555555 } /* Generic.Prompt */
|
||||
.highlight .gs { font-weight: bold } /* Generic.Strong */
|
||||
.highlight .gu { color: #aaaaaa } /* Generic.Subheading */
|
||||
.highlight .gt { color: #aa0000 } /* Generic.Traceback */
|
||||
.highlight .kc { font-weight: bold } /* Keyword.Constant */
|
||||
.highlight .kd { font-weight: bold } /* Keyword.Declaration */
|
||||
.highlight .kp { font-weight: bold } /* Keyword.Pseudo */
|
||||
.highlight .kr { font-weight: bold } /* Keyword.Reserved */
|
||||
.highlight .kt { color: #445588; font-weight: bold } /* Keyword.Type */
|
||||
.highlight .m { color: #009999 } /* Literal.Number */
|
||||
.highlight .s { color: #d14 } /* Literal.String */
|
||||
.highlight .na { color: #008080 } /* Name.Attribute */
|
||||
.highlight .nb { color: #0086B3 } /* Name.Builtin */
|
||||
.highlight .nc { color: #445588; font-weight: bold } /* Name.Class */
|
||||
.highlight .no { color: #008080 } /* Name.Constant */
|
||||
.highlight .ni { color: #800080 } /* Name.Entity */
|
||||
.highlight .ne { color: #990000; font-weight: bold } /* Name.Exception */
|
||||
.highlight .nf { color: #990000; font-weight: bold } /* Name.Function */
|
||||
.highlight .nn { color: #555555 } /* Name.Namespace */
|
||||
.highlight .nt { color: #000080 } /* Name.Tag */
|
||||
.highlight .nv { color: #008080 } /* Name.Variable */
|
||||
.highlight .ow { font-weight: bold } /* Operator.Word */
|
||||
.highlight .w { color: #bbbbbb } /* Text.Whitespace */
|
||||
.highlight .mf { color: #009999 } /* Literal.Number.Float */
|
||||
.highlight .mh { color: #009999 } /* Literal.Number.Hex */
|
||||
.highlight .mi { color: #009999 } /* Literal.Number.Integer */
|
||||
.highlight .mo { color: #009999 } /* Literal.Number.Oct */
|
||||
.highlight .sb { color: #d14 } /* Literal.String.Backtick */
|
||||
.highlight .sc { color: #d14 } /* Literal.String.Char */
|
||||
.highlight .sd { color: #d14 } /* Literal.String.Doc */
|
||||
.highlight .s2 { color: #d14 } /* Literal.String.Double */
|
||||
.highlight .se { color: #d14 } /* Literal.String.Escape */
|
||||
.highlight .sh { color: #d14 } /* Literal.String.Heredoc */
|
||||
.highlight .si { color: #d14 } /* Literal.String.Interpol */
|
||||
.highlight .sx { color: #d14 } /* Literal.String.Other */
|
||||
.highlight .sr { color: #009926 } /* Literal.String.Regex */
|
||||
.highlight .s1 { color: #d14 } /* Literal.String.Single */
|
||||
.highlight .ss { color: #990073 } /* Literal.String.Symbol */
|
||||
.highlight .bp { color: #999999 } /* Name.Builtin.Pseudo */
|
||||
.highlight .vc { color: #008080 } /* Name.Variable.Class */
|
||||
.highlight .vg { color: #008080 } /* Name.Variable.Global */
|
||||
.highlight .vi { color: #008080 } /* Name.Variable.Instance */
|
||||
.highlight .il { color: #009999 } /* Literal.Number.Integer.Long */
|
||||
0
data/.gitkeep
Normal file
0
data/.gitkeep
Normal file
@ -1,13 +1,12 @@
|
||||
version: "3"
|
||||
version: '3'
|
||||
|
||||
services:
|
||||
site:
|
||||
command: jekyll serve
|
||||
image: jekyll/jekyll:latest
|
||||
volumes:
|
||||
- ./:/srv/jekyll
|
||||
- ./vendor/bundle:/usr/local/bundle
|
||||
app:
|
||||
build:
|
||||
dockerfile: Dockerfile.dev
|
||||
context: .
|
||||
ports:
|
||||
- 4000:4000
|
||||
- 35729:35729
|
||||
- 3000:3000
|
||||
- 80:4000
|
||||
- "1313:1313"
|
||||
working_dir: /src/
|
||||
volumes:
|
||||
- ./:/src/
|
||||
@ -1,29 +0,0 @@
|
||||
document.onreadystatechange = function () {
|
||||
if (this.readyState === "complete") {
|
||||
|
||||
var createAnchorLink = function (id) {
|
||||
var anchor = document.createElement("a");
|
||||
anchor.className = "anchor-link";
|
||||
anchor.href = "#" + id;
|
||||
return anchor;
|
||||
};
|
||||
|
||||
// Add IDs to all spec li elements
|
||||
var specItems = document.querySelectorAll("#spec ol")[1]
|
||||
.querySelectorAll('li');
|
||||
for (var i = 0; i < specItems.length; i++)
|
||||
{
|
||||
var li = specItems[i];
|
||||
li.id = 'spec-item-' + (i + 1);
|
||||
}
|
||||
|
||||
// Add anchor link to all elements with an ID in the spec
|
||||
var headers = document.querySelectorAll('#spec [id]');
|
||||
for (var i = 0; i < headers.length; i++)
|
||||
{
|
||||
var element = headers[i];
|
||||
var anchorLink = createAnchorLink(element.id);
|
||||
element.insertBefore(anchorLink, element.firstChild)
|
||||
}
|
||||
}
|
||||
};
|
||||
@ -1,249 +0,0 @@
|
||||
---
|
||||
title: Commits Convencionales 1.0.0-beta.2
|
||||
language: es
|
||||
---
|
||||
|
||||
# Commits Convencionales 1.0.0-beta.2
|
||||
|
||||
## Resumen
|
||||
|
||||
Al mantener proyectos de código abierto, cuando se incorporan ramas con nuevas
|
||||
características en `master` al escribir un mensaje de commit estandarizado, el
|
||||
mensaje del commit debe estar estructurado de la siguiente forma:
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
<tipo>[ámbito opcional]: <descripción>
|
||||
|
||||
[cuerpo opcional]
|
||||
|
||||
[nota de pie opcional]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
<br />
|
||||
El commit contiene los siguientes elementos estructurales para comunicar la
|
||||
intención al consumidor de la librería:
|
||||
|
||||
1. **fix:** un commit de _tipo_ `fix` corrige un error en la base del código
|
||||
(se correlaciona con [`PATCH`](http://semver.org/#summary) en el versionado
|
||||
semántico).
|
||||
2. **feat:** un commit de _tipo_ `feat` introduce nuevas características en la
|
||||
base del código (se correlaciona con [`MINOR`](http://semver.org/#summary)
|
||||
en el versionado semántico).
|
||||
3. **BREAKING CHANGE:** un commit que contiene el texto `BREAKING CHANGE:` al
|
||||
inicio de su cuerpo opcional o la sección de nota de pie introduce un cambio
|
||||
en el uso de la API (se correlaciona con [`MAJOR`](http://semver.org/#summary)
|
||||
en el versionado semántico). Un cambio en el uso de la API puede ser parte
|
||||
de commits de _tipo_. e.g., a `fix:`, `feat:` & `chore:` todos tipos
|
||||
válidos, adicional a cualquier otro _tipo_.
|
||||
4. Otros: _tipos_ de commits distintos a `fix:` y `feat:` están permitidos, por
|
||||
ejemplo [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional)
|
||||
(basado en [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines))
|
||||
recomienda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` y
|
||||
otros. También recomendamos `improvement` para commits que mejorar una
|
||||
implementación actual sin añadir nuevas características ni corregir errores.
|
||||
Tenga presente que estos tipos no son impuestos por la especificación de
|
||||
commits convencionales y no tienen efecto implícito en el versionado
|
||||
semántico (a menos que incluyan el texto BREAKING CHANGE, lo cual NO es
|
||||
recomendado).
|
||||
<br />
|
||||
Se puede agregar un ámbito al _tipo_ de commit para proveer información
|
||||
contextual adicional y se escribe entre paréntesis, e.g., `feat(parser): add ability to parse arrays`.
|
||||
|
||||
## Ejemplos
|
||||
|
||||
### Mensaje de commit con descripción y cambio en el uso de la API en el cuerpo
|
||||
|
||||
```
|
||||
feat: allow provided config object to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||
```
|
||||
|
||||
### Mensaje de commit sin cuerpo
|
||||
|
||||
```
|
||||
docs: correct spelling of CHANGELOG
|
||||
```
|
||||
|
||||
### Mensaje de commit con ámbito
|
||||
|
||||
```
|
||||
feat(lang): added polish language
|
||||
```
|
||||
|
||||
### Mensaje de commit para una corrección usando un número de problema (opcional)
|
||||
|
||||
```
|
||||
fix: minor typos in code
|
||||
|
||||
see the issue for details on the typos fixed
|
||||
|
||||
fixes issue #12
|
||||
```
|
||||
|
||||
## Introducción
|
||||
|
||||
En el desarrollo de software, ha sido mi experiencia que los errores en el
|
||||
código son introducidos con más frecuencia en las fronteras de la aplicación.
|
||||
Los tests unitarios funcionan muy bien para probar las interacciones que el
|
||||
mantenedor conoce, pero hacen un mal trabajo capturando la manera interesante,
|
||||
a veces inesperada, en que una comunidad usa una librería.
|
||||
|
||||
Cualquiera que haya actualizado una versión corregida de una dependencia para
|
||||
luego darse cuenta de que la aplicación empieza a arrojar un flujo de 500
|
||||
errores, sabe lo importante que es un historial de commits legible (e
|
||||
[idealmente un bien mantenido CHANGELOG](http://keepachangelog.com/en/0.3.0/))
|
||||
para el consiguiente proceso forense.
|
||||
|
||||
La especificación de Commits Convencionales propone introducir una convención
|
||||
estandarizada y ligera sobre los mensajes de los commits. Esta convención encaja
|
||||
con [SemVer](http://semver.org), pidiéndole a los desarrolladores de software
|
||||
describir en los mensajes de los commits, las características, correcciones y
|
||||
cambios que rompen el uso de la API que hagan.
|
||||
|
||||
Al introducir esta convención, creamos un lenguaje común que permite depurar más
|
||||
fácilmente los problemas a través de las fronteras de un proyecto.
|
||||
|
||||
## Especificación de Commits Convencionales
|
||||
|
||||
Las palabras “DEBE” (“MUST”), “NO DEBE” (“MUST NOT”), “REQUIERE” (“REQUIRED”),
|
||||
“DEBERÁ” (“SHALL”), “NO DEBERÁ” (“SHALL NOT”), “DEBERÍA” (“SHOULD”),
|
||||
“NO DEBERÍA” (“SHOULD NOT”), “RECOMIENDA” (“RECOMMENDED”), “PUEDE” (“MAY”) Y
|
||||
“OPCIONAL” (“OPTIONAL”) en este documento se deben interpretar como se describe
|
||||
en [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Los commits DEBEN iniciar con un tipo que consiste en un sustantivo `feat`, `fix`, etc.,
|
||||
seguido de dos puntos y un espacio.
|
||||
2. El tipo `feat` DEBE ser usado cuando un commit agrega una nueva
|
||||
característica a la aplicación o librería.
|
||||
3. El tipo `fix` DEBE ser usado cuando el commit representa una corrección a un
|
||||
error en el código de la aplicación.
|
||||
4. Se PUEDE añadir un ámbito opcional después del tipo. El ámbito es una frase
|
||||
que describe una sección de la base del código encerrada en paréntesis,
|
||||
e.g., `fix(parser):`
|
||||
5. Una descripción DEBE ir inmediatamente después del tipo/ámbito inicial y es
|
||||
una descripción corta de los cambios realizados en el código, e.g.,
|
||||
_fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. Un cuerpo del commit más extenso PUEDE agregarse después de la descripción,
|
||||
dando información contextual adicional acerca de los cambios en el código.
|
||||
El cuerpo DEBE iniciar con una línea en blanco después de la descripción.
|
||||
7. Una nota de pie PUEDE agregarse tras una línea en blanco después del
|
||||
cuerpo o después de la descripción en caso de que no se haya dado un cuerpo.
|
||||
La nota de pie DEBE contener referencias adicionales a los números de
|
||||
problemas registrados sobre el cambio del código (como el número de problema
|
||||
que corrige, e.g.,`Fixes #13`).
|
||||
8. Los cambios que rompen la API DEBEN ser indicados al inicio de la nota de
|
||||
pie o el cuerpo del commit. Un cambio que rompe la API DEBE contener el
|
||||
texto en mayúsculas `BREAKING CHANGE`, seguido de dos puntos y espacio.
|
||||
9. Una descripción se DEBE proveer después de `BREAKING CHANGE:`, describiendo
|
||||
qué ha cambiado en la API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. La nota de pie DEBE contener solamente el texto `BREAKING CHANGE`, vínculos
|
||||
externos, referencias a problemas u otra metainformación.
|
||||
11. Otros tipos distintos a `feat` y `fix` PUEDEN ser usados en los mensajes de
|
||||
los commits.
|
||||
|
||||
## ¿Por qué usar Commits Convencionales?
|
||||
|
||||
* Generación automática de CHANGELOGs.
|
||||
* Determinación automática de los cambios de versión (basado en los tipos de
|
||||
commits).
|
||||
* Comunicar la naturaleza de los cambios a los demás integrantes del equipo, el
|
||||
público o cualquier otro interesado.
|
||||
* Ejecutar procesos de ejecución y publicación.
|
||||
* Hacer más fácil a otras personas contribuir al proyecto, permitiendo explorar
|
||||
una historia de los commits más estructurada.
|
||||
|
||||
## FAQ
|
||||
|
||||
### ¿Cómo puedo trabajar con los mensajes de los commits en la etapa inicial de desarrollo?
|
||||
|
||||
Recomendamos trabajar como si ya hubiera lanzado su producto. Típicamente
|
||||
_alguien_, incluso si son sus compañeros desarrolladores, están usando su
|
||||
producto. Ellos querrán saber que se ha arreglado, que se ha dañado, etc.
|
||||
|
||||
### ¿Qué debo hacer si un commit encaja en más de un tipo de commit?
|
||||
|
||||
Regrese y haga múltiples commits de ser posible. Parte de los beneficios de los
|
||||
Commits Convencionales es la habilidad para hacer commits más organizados y así
|
||||
mismo PRs.
|
||||
|
||||
### ¿No desalienta esto el desarrollo y la iteración rápida?
|
||||
|
||||
Desalienta moverse rápido de una forma desorganizada. Ayuda a moverse rápido a
|
||||
largo plazo a través de proyectos con una gran variedad de contribuidores.
|
||||
|
||||
### ¿Pueden los Commits Convencionales llevar a los desarrolladores a limitar el tipo de commits que hacen ya que estarán pensando en los tipos previstos?
|
||||
|
||||
Los Commits Convencionales nos animan a hacer más de cierto tipo de commits como
|
||||
_fixes_. Adicionalmente, la flexibilidad de los Commits Convencionales permite
|
||||
a su equipo generar sus propios tipos y cambiarlos a lo largo del tiempo.
|
||||
|
||||
### ¿Cómo se relaciona esto con SemVer?
|
||||
|
||||
El tipo de commit `fix` se traduce a un cambio de versión `PATCH`. El tipo de
|
||||
commit `feat` se traduce a un cambio de versión `MINOR`. Commits con el texto
|
||||
`BREAKING CHANGE`, sin importar su tipo, se traducen a un cambio de versión
|
||||
`MAJOR`.
|
||||
|
||||
### ¿Cómo puedo versionar mis extensiones a la especificación de Commits Convencionales, e.g. `@jameswomack/conventional-commit-spec`?
|
||||
|
||||
Recomendamos usar SemVer para liberar su propia extensión a esta especificación
|
||||
(¡y lo animamos a hacer esta extensión!)
|
||||
|
||||
### ¿Qué debo hacer si por accidente uso un tipo de commit equivocado?
|
||||
|
||||
#### Cuando utiliza un tipo que es de la especificación pero no es el correcto, e.g. `fix` en lugar de `feat`
|
||||
|
||||
Antes de combinar o liberar el error, recomendamos usar `git rebase -i` para
|
||||
editar la historia de los commits. Después de que se ha liberado, la limpieza
|
||||
será distinta de acuerdo con las herramientas y procesos que usted use.
|
||||
|
||||
#### Cuanto se usa un tipo que no está en la especificación, e.g. `feet` instead of `feat`
|
||||
|
||||
En el peor de los escenarios, no es el fin del mundo si aparece un commit que no
|
||||
cumple con las especificaciones de los commits convencionales. Simplemente, el
|
||||
commit será ignorado por las herramientas que se basen en esta especificación.
|
||||
|
||||
### ¿Deben todos los que contribuyen a mi proyecto usar esta especificación?
|
||||
|
||||
¡No! Si usa un flujo de trabajo basado en `squash` los líderes del proyecto
|
||||
pueden limpiar el mensaje en el momento en que se incorpora, sin agregar cargas
|
||||
adicionales a quienes contribuyen casualmente. Un flujo de trabajo común para
|
||||
esto es configurar su sistema de git para que haga el `squash` de manera
|
||||
automática de un pull request y presente al líder del proyecto un formulario
|
||||
para que ingrese el mensaje de commit correcto al momento de hacer el merge.
|
||||
|
||||
## Acerca de
|
||||
|
||||
La especificación de Commits Convencionales está inspirada, y fuertemente
|
||||
basada, en [Angular Commit Guidelines](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
|
||||
|
||||
El primer borrador de esta especificación ha sido escrito en colaboración con
|
||||
algunos de los colaboradores de:
|
||||
|
||||
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog):
|
||||
una serie de herramientas para analizar los mensajes de los commits de los
|
||||
historiales de git.
|
||||
* [unleash](https://github.com/netflix/unleash): una herramienta para
|
||||
automatizar la liberación de software y ciclo de vida de publicación.
|
||||
* [lerna](https://github.com/lerna/lerna): una herramienta para manejar
|
||||
mono-repositorios, que creció a partir del proyecto Babel.
|
||||
|
||||
## Proyectos usando Commits Convencionales
|
||||
|
||||
* [yargs](https://github.com/yargs/yargs): el analizador de argumentos de la línea de comandos preferido por todos.
|
||||
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): una colección de herramientas y librerías de código abierto para agregar cobertura de código a sus tests.
|
||||
* [standard-version](https://github.com/conventional-changelog/standard-version): versionado automático y manejos de CHANGELOG, usando el botón de squash de GitHub y siguiendo el flujo de trabajo de los Commits Convencionales.
|
||||
* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) y [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): mejoramiento opcional para la interfaz de usuario [Apereo uPortal](https://www.apereo.org/projects/uportal).
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_¿Quiere ver su proyecto en esta lista?_ [haga un pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencia
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,194 +0,0 @@
|
||||
---
|
||||
title: Commit Convenzionali 1.0.0-beta.2
|
||||
language: it
|
||||
---
|
||||
|
||||
# Commit Convenzionali 1.0.0-beta.2
|
||||
|
||||
## Riepilogo
|
||||
|
||||
Da maintainer di codice open source, devo poter scrivere messaggi standardizzati per i commit
|
||||
ed eseguire lo squash dei feature branch nel `master`.
|
||||
|
||||
I messaggi dei commit dovrebbero seguire la seguente struttura:
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
<tipo>[contesto opzionale]: <descrizione>
|
||||
|
||||
[corpo opzionale]
|
||||
|
||||
[piè di pagina opzionale]
|
||||
```
|
||||
---
|
||||
|
||||
<br />
|
||||
Il commit contiene i seguenti elementi strutturali, allo scopo di comunicarne
|
||||
l'intento al consumatore della libreria:
|
||||
|
||||
1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
|
||||
2. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
3. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
|
||||
Una _breaking change_ può essere parte di un commit di qualsiasi _tipo_. Es: I tipi `fix:`, `feat:` & `chore:` sono tutti validi, cosí come qualsiasi altro _tipo_.
|
||||
4. Extra: sono ammessi ulteriori _tipi_ oltre `fix:` e`feat:`, per esempio [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (che si basa sulla [convenzione Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) raccomanda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
|
||||
Noi raccomandiamo anche `improvement` per commit che migliorano un'implementazione esistente senza aggiungere nuove funzionalità o risolvere un errore.
|
||||
Notare che questi _tipi_ non sono mantenuti da questa specifica, e non hanno un effetto sul versionamento semver (a meno che non introducano una _BREAKING CHANGE_, il quale NON è raccomandato).
|
||||
<br />
|
||||
Un _contesto_ potrebbe essere aggiunto al _tipo_ di commit, al fine di offrire ulteriori informazioni contestuali.
|
||||
Da aggiungere tra delle parentesi tonde, Es: `feat(parser): add ability to parse arrays`.
|
||||
|
||||
## Esempi
|
||||
|
||||
### Messaggio di un commit con una _descrizione_ e una breaking change nel _corpo_
|
||||
```
|
||||
feat: allow provided config object to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||
```
|
||||
|
||||
### Messaggio di un commit senza una _descrizione_
|
||||
```
|
||||
docs: correct spelling of CHANGELOG
|
||||
```
|
||||
|
||||
### Messaggio di un commit con uno _contesto_
|
||||
```
|
||||
feat(lang): added polish language
|
||||
```
|
||||
|
||||
### Messaggio di un commit per un `fix` utilizzando il numero della issue (opzionale)
|
||||
```
|
||||
fix: minor typos in code
|
||||
|
||||
see the issue for details on the typos fixed
|
||||
|
||||
fixes issue #12
|
||||
```
|
||||
|
||||
## Introduzione
|
||||
|
||||
Nello sviluppo software, secondo la mia esperienza, gli errori sono spesso introdotti ai limiti tra le applicazioni.
|
||||
|
||||
I test unitari vanno benissimo per le interazioni che i mantenitori open source conoscono,
|
||||
ma non fanno un ottimo lavoro nel catturare tutti i modi interessanti, spesso inaspettati, con i quali la comunità utilizza una libreria.
|
||||
|
||||
Solamente chi ha visto la propria applicazione restituire errori 500
|
||||
dopo aver aggiornato una dipendenza ad una nuova versione patch,
|
||||
sa quanto sia importante una cronologia di commit facilmente leggibile
|
||||
(e nel migliore dei casi [un CHANGELOG ben mantenuto](http://keepachangelog.com/en/0.3.0/))
|
||||
per il processo di investigazione che dovrà affrontare.
|
||||
|
||||
La specifica per commit convenzionali propone l'introduzione di una convenzione
|
||||
facilmente applicabile ai messaggi dei commit.
|
||||
Questa convenzione legata al [SemVer](http://semver.org), chiede ai sviluppatori software
|
||||
di descrivere nei messaggi dei commit qualsiasi feature, fix e breaking change loro abbiano fatto.
|
||||
|
||||
Introducendo questa convenzione, si crea un linguaggio comune che rende più semplice
|
||||
rimuovere errori tra progetti.
|
||||
|
||||
## Specifica Commit Convenzionali
|
||||
|
||||
Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc.,
|
||||
seguito dai due punti ed uno spazio.
|
||||
2. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
|
||||
all'applicazione o libreria.
|
||||
3. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
|
||||
4. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
|
||||
Un _contesto_ rappresenta una sezione dell'applicazione o libreria, il contentuo va racchiusa tra delle parentesi.
|
||||
Es: `fix(parser):`
|
||||
5. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
|
||||
Per _descrizione_ si intende una breve spiegazione riguardo la modifica al codice.
|
||||
Es: _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_, aggiungendo ulteriori informazioni contestuali riguardo le modifiche apportate al codice.
|
||||
Il _corpo_ DEVE inizare dopo una linea vuota dalla _descrizione_.
|
||||
7. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
|
||||
Il _piè di pagina_ DOVREBBE contenere ulteriori informazioni riguardo le modifiche apportate al codice (come le issue che risolve,
|
||||
Es: `fixes #13, #5`).
|
||||
8. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
|
||||
Una _breaking change_ DEVE essere scritta in maiuscolo `BREAKING CHANGE`, seguita dai due punti ed uno spazio.
|
||||
9. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
|
||||
Es: _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. Il _piè di pagina_ DEVE solo contentere `BREAKING CHANGE`, collegamenti esterni, riferimenti alle issueed ulteriori meta-informazioni.
|
||||
11. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messagio.
|
||||
|
||||
## Perchè utilizzare commit convenzionali
|
||||
|
||||
* CHANGELOG generati automaticamente.
|
||||
* Determina automaticamente l'incremento di un versionamento semver (basandosi sui tipi di commit utilizzati).
|
||||
* Comunica la natura dei cambiamenti a colleghi, pubblico, o altri parti interessate.
|
||||
* Attiva build e processi di rilascio.
|
||||
* Rendi più semplice alle persone contribuire al tuo progetto, dando la possibilità di espolrare una cronologia di commit più strutturata.
|
||||
|
||||
## FAQ
|
||||
|
||||
### Come dovrei comportarmi con i messaggi dei commit nella fase iniziale del progetto?
|
||||
|
||||
Raccomandiamo di procedere come se il tuo prodotto sia già stato rilasciato. Tipicamente *qualcuno*, anche i tuoi colleghi, stanno utilizzando il tuo software. Loro vorranno sapere cosa sia stato risolto, cosa si sia rotto etc.
|
||||
|
||||
### Cosa faccio se il tipo di commit è conforme a più di un tipo?
|
||||
|
||||
Torna indietro e dividi in più commit dove puoi.
|
||||
Parte del beneficio di usare Commit Convenzionali è quello di spingerti a fare commit e pull request più organizzati.
|
||||
|
||||
### Non disincoraggia sviluppo ed iterazioni rapidi?
|
||||
|
||||
Disingoraggia farlo in una maniere disorgaizzata. Inoltre ti aiuterà a muoverti più velocemente su più progetti con diversi contributori.
|
||||
|
||||
### Potrebbe Commit Convenzionali limitare gli sviluppatori a fare solamente alcuni tipi commit perchè penseranno nei tipi forniti dalla specifica?
|
||||
|
||||
Commit Convenzionali ti incoraggia nel fare più di certi tipi di commit.
|
||||
Inoltre la flessibilità di Commit Convenzionali consente al tuo team di inventare i propri tipi e cambiarli nel tempo.
|
||||
|
||||
### Come si collega a SemVer?
|
||||
|
||||
I commit di tipo `fix` dovrebbero essere traducibili ai rilasci `PATCH`.
|
||||
I commit di tipo `feat` dovrebbero essere traducibili ai rilasci `MINOR`.
|
||||
I commit con `BREAKING CHANGE`, indipentemente dal tipo, dovrebbero essere traducibili ai rilasci `MAJOR`.
|
||||
|
||||
### Come dovrei versionare le mie estensioni per la specifica Commit Convenzionali? (Es: `@jameswomack/conventional-commit-spec`)
|
||||
|
||||
Raccomandiamo l'utilizzo di SemVer per rilasciare la tua estensione (crea delle estensioni!)
|
||||
|
||||
### Cosa faccio se accidentalmente utilizzo un tipo di commit sbagliato?
|
||||
|
||||
#### Quando usi un tipo della specifica ma non quello giusto (Es: `fix` invece di `feat`)
|
||||
|
||||
Se ancora devi creare il merge o il rilascio dell'errore, raccomandiamo l'utilizzo di `git rebase -i` per riscrivere la cronologia dei commit.
|
||||
Nel caso ti abbia già rilasciato questa correzzione dipende dai tool e processi che usi.
|
||||
|
||||
#### Quando usi un tipo *non* della specifica (Es: `feet` invece di `feat`)
|
||||
|
||||
Non è la fine del mondo se un commit non segue la specifica Commit Convenzionali.
|
||||
Semplicemente il commit verrà ignorato dai tool che sono basati su questa specifica.
|
||||
|
||||
### Devono tutti i contributori seguire la specifica Commit Convenzionali?
|
||||
|
||||
No. Se usi un workflow basato sugli squash di Git, i mantenitori possono pulire i messaggi dei commit mentre vengono inseriti nel branch principale (merge), non aggiungendo alcun carico di lavoro ai committer occasionali.
|
||||
Un workflow comune è quello di unire (con lo squash) automaticamente i commit dalle pull request e far utilizzare un form ai mantenitori per riscrivere un messaggio più adeguato.
|
||||
|
||||
## Riguardo
|
||||
|
||||
La specifica Commit Convenzionali è ispirata e fortemente basata su [Angular Commit Guidelines](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
|
||||
|
||||
La prima bozza di questa specifica è stata scritta in collaborazione con alcuni contributori di:
|
||||
|
||||
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): un set di tool per analizzare messagi dei commit convenzionali dalla cronologia git.
|
||||
* [unleash](https://github.com/netflix/unleash): un tool per automatizzare rilasci e cicli di pubblicazioni di un software.
|
||||
* [lerna](https://github.com/lerna/lerna): un tool per la gestione di monorepos, nato del progetto Babel.
|
||||
|
||||
## Progetti che usano Commit Convenzionali
|
||||
|
||||
* [yargs](https://github.com/yargs/yargs): Parser di argomenti da CLI, a tema pirati.
|
||||
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): Una collezione di strumenti e librerie open source per aggiungere la coverage dei test JavaScript.
|
||||
* [standard-version](https://github.com/conventional-changelog/standard-version): Automatizza il versionamento e la gestione del CHANGELOG utilizzando il nuovo pulsante squash di GitHub e il flusso di lavoro consigliato da Commit Convenzionali.
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_vuoi aggingere il tuo progetto alla lista?_ [invia una pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licenza
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,187 +0,0 @@
|
||||
---
|
||||
title: Konwencjonalne Commity 1.0.0-beta.2
|
||||
language: pl
|
||||
---
|
||||
|
||||
# Konwencjonalne Commity 1.0.0-beta.2
|
||||
|
||||
## Streszczenie
|
||||
|
||||
Jako opiekun otwartych źródeł, spłaszczaj (squashuj) gałęzie funkcyjne (featurowe) do gałęzi głównej - `master`
|
||||
oraz pisz ustandaryzowane opisy dostarczeń (commitów).
|
||||
|
||||
Opis dostarczenia powinien wyglądać następująco:
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
<typ>[opcjonalny zakres]: <opis>
|
||||
|
||||
[opcjonalne ciało wiadomości]
|
||||
|
||||
[opcjonalna stopka wiadomości]
|
||||
```
|
||||
---
|
||||
|
||||
<br />
|
||||
Wiadomość zawiera następujące strukturalne elementy po to, aby zakomunikować intencje
|
||||
do użytkowników Twojej biblioteki:
|
||||
|
||||
1. **fix:** dostarczenie _typu_ `fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
3. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:` & `chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
|
||||
4. Inne: commity _typu_ innego niż `fix:` oraz `feat:` są dozwolone, np. [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (bazowano na [konwencji Angulara](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) poleca `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, oraz inne. My polecamy także `improvement` dla dostarczeń, które ulepszają obecną implementację bez dodawania nowych funkcjonalności lub naprawy błędów. Zauważ, że te typy nie są obowiązkowe według specyfikacji konwencjonalnych commitów i nie mają wpływu na wersjonowanie (chyba, że zawierają BREAKING CHANGE, co NIE JEST rekomendowane).
|
||||
<br />
|
||||
Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
|
||||
Zawiera się on w nawiasach następujących bezpośrednio po typie, np. `feat(parser): dodano możliwość parsowania list`.
|
||||
|
||||
## Przykłady
|
||||
|
||||
### Commit z opisem oraz zmianą niekomatybilną wstecz (BREAKING CHANGE)
|
||||
```
|
||||
feat: pozwól dostarczonemu obiektowi konfiguracyjnemu na rozszerzanie innych konfiguracji
|
||||
|
||||
BREAKING CHANGE: klucz `extends` i pliku konfiguracyjnym jest teraz używany do rozszerzania innych konfiguracji
|
||||
```
|
||||
|
||||
### Commit bez ciała wiadomości
|
||||
```
|
||||
docs: poprawniono pisownię w CHANGELOG
|
||||
```
|
||||
|
||||
### Commit z określonym zakresem
|
||||
```
|
||||
feat(lang): dodano język polski
|
||||
```
|
||||
|
||||
### Commit dostarczenia naprawiającego buga określonego w raporcie błędu (issue) o (opcjonalnym) numerze
|
||||
```
|
||||
fix: kilka literówek w kodzie
|
||||
|
||||
po więcej szczegółów udaj się do raportu błędu
|
||||
|
||||
fixes issue #12
|
||||
```
|
||||
|
||||
## Wprowadzenie
|
||||
|
||||
Podczas rozwoju oprogramowania zauważyłem, że błędy często występują na granicy
|
||||
pomiędzy aplikacjami. Testy jednostkowe doskonale zdają egzamin w przypadkach, o których
|
||||
opiekun biblioteki pomyślał, jednak sposoby, w jakich oprogramowanie zostanie użyte
|
||||
przez społeczność często, choć interesujące mogą być nie do pomyślenia.
|
||||
Tutaj testy jednostkowe niezbyt zdają egzamin.
|
||||
|
||||
Każdy, kto kiedykolwiek zaktualizował zależność swojej aplikacji, chociażby o jedną wersję _patch_,
|
||||
tylko po to, aby zobaczyć, jak jego aplikacja zaczyna rzucać 500 błędami, wie,
|
||||
jak ważną rolę stanowi czytelna historia dostarczeń (oraz dodatkowo [dobrze zarządzany DZIENNIK ZMIAN (CHANGELOG)](http://keepachangelog.com/en/0.3.0/))
|
||||
podczas naprawy.
|
||||
|
||||
Specyfikacja Konwencjonalnych Commitów proponuje wprowadzenie ustandaryzowanej, lekkiej
|
||||
konwencji wykorzystującej wiadomości w dostarczeniach. Konwencja ta łączy się z [SemVer](http://semver.org),
|
||||
nakazując deweloperom opisywanie w wiadomościach podczas dostarczania jakie funkcje wprowadzają, co naprawiają
|
||||
oraz jakie niekompatybilne wstecz zmiany wnoszą.
|
||||
|
||||
Wprowadzając tę konwencję, tworzymy powszechny język, który pozwala na dużo łatwiejsze
|
||||
wyłapywanie błędów występujących na granicy projektu z jego zależnościami.
|
||||
|
||||
## Specyfikacja Konwencjonalnych Commitów
|
||||
|
||||
Następujące terminy “MUSI” (“MUST”), “NIE MOŻE” (“MUST NOT”), “WYMAGANY” (“REQUIRED”), “MA BYĆ” (“SHALL”), “NIE BĘDZIE” (“SHALL NOT”), “POWINIEN” (“SHOULD”), “NIE POWINIEN” (“SHOULD NOT”), “ZALECANY” (“RECOMMENDED”), “MOŻE” (“MAY”) oraz “OPCJONALNY” (“OPTIONAL”) pojawiające się w tym dokumencie rozumiane są zgodnie z ich opisem na stronie: [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Dostarczenie MUSI być poprzedzone typem, który składa się z rzeczownika, np. `feat`, `fix`, itp.,
|
||||
oraz następującymi bezpośrednio po nim dwukropka oraz spacji.
|
||||
2. Typ `feat` MUSI być użyty, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź biblioteki.
|
||||
3. Typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
4. Opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
5. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
Opis jest to krótka notka stanowiąca o treści dostarczenia, np.,
|
||||
_fix: problem podczas parsowania listy, kiedy string zawierał wiele spacji._
|
||||
6. Dłuższe ciało wiadomości MOŻE być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
7. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiązuje, np. `fixes #13, #5`.
|
||||
8. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadomości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
9. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
|
||||
np. _BREAKING CHANGE: zmienne środowiskowe mają teraz większy priorytet niż pliki konfiguracyjne._
|
||||
10. Stopka powinna zawierać tylko i wyłącznie `BREAKING CHANGE`, linki zewnętrzne, odnośniki do raportów błędów oraz inne meta-informacje.
|
||||
11. Typy inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
|
||||
## Dlaczego używać Konwencjonalnych Commitów
|
||||
|
||||
* Automatycznie generowany DZIENNIK ZMIAN.
|
||||
* Automatycznie wykrywana zmiana semantycznej zmiany wersji (określana na podstawie typów dostarczonych zmian)
|
||||
* Komunikowanie zmian członkom zespołu, publice, oraz innym zainteresowanym.
|
||||
* Wyzwalanie procesów budowania oraz publikacji.
|
||||
* Łatwiejsze włączenie się w rozwój kodu przez ludzi z zewnątrz poprzez pozwolenie im na przeglądanie
|
||||
bardziej zorganizowanej historii dostarczeń.
|
||||
|
||||
## FAQ
|
||||
|
||||
### Jak powinienem radzić sobie z wiadomościami dostarczeń w fazie początkowej rozwoju kodu?
|
||||
|
||||
Polecamy, żebyś postępował tak, jakby Twój produkt już został wydany. Zazwyczaj *ktoś*, nawet jeśli jest to Twój kolega z zespołu, już
|
||||
używa Twojego oprogramowania. Będzie chciał wiedzieć, co zostało naprawione, co nie działa itp.
|
||||
|
||||
### Co powinienem zrobić, jeśli dostarczenie pasuje do więcej niż jednego typu?
|
||||
|
||||
Wróć się i stwórz więcej dostarczeń, jeśli to tylko możliwe. Częściową korzyścią z Konwencjonalnych Commitów jest zdolność do tworzenia kodu
|
||||
w bardziej zorganizowany sposób.
|
||||
|
||||
### Czy takie podejście nie zniechęca do szybkiego rozwoju oraz szybkich iteracji?
|
||||
|
||||
Zniechęca do szybkiego poruszania się do przodu w niezorganizowany sposób. Pozwala Ci na szybkie posuwanie się do przodu w wielu projektach oraz
|
||||
różnorodnych deweloperów.
|
||||
|
||||
### Czy Konwencjonalne Commity mogą prowadzić do zmniejszenia ilości typów dostarczanych przez deweloperów, ponieważ będą myśleć w przestrzeni wymienionych typów?
|
||||
|
||||
Konwencjonalne Commity zachęcają do tworzenia większej ilości dostarczeń danego typu, np. napraw. Z innego punktu widzenia, elastyczność
|
||||
Konwencjonalnych Commitów pozwala Twojemu zespołowi stworzyć własne typy oraz zmieniać je z biegiem czasu.
|
||||
|
||||
### Jak jest to powiązane z SemVer?
|
||||
|
||||
Wiadomości typu `fix` powinny być traktowane tak jak `PATCH`. Wiadomości typu `feat` tak jak `MINOR`, natomiast dostarczenia zawierające `BREAKING CHANGE`, bez względu na typ, powinny być traktowane jak `MAJOR`.
|
||||
|
||||
### Jak powinienem wersjonować moje rozszerzenia zgodnie ze specyfikacją Konwencjonalnych Commitów, np. `@jameswomack/conventional-commit-spec`?
|
||||
|
||||
Zalecamy używanie SemVer do wydawania własnych rozszerzeń do tej specyfikacji (oraz zachęcamy do tworzenia tych rozszerzeń!).
|
||||
|
||||
### Co powinienem zrobić, jeśli przypadkowo użyje błędnego typu dostarczenia?
|
||||
|
||||
#### Jeśli użyłeś typu, który znajduje się w specyfikacji, ale nie jest poprawny, np. `fix` zamiast `feat`
|
||||
|
||||
Przed dostarczeniem i wydaniem pomyłki, polecamy użyć `git rebase -i` w celu zmienienia historii dostarczeń. Zmiana po dostarczeniu zależy od narzędzi oraz procesów, których używasz.
|
||||
|
||||
#### Jeśli użyłeś typu, który *nie* znajduje się w specyfikacji, np. `feet` zamiast `feat`
|
||||
|
||||
W najgorszym przypadku - to nie koniec świata, jeśli dostarczenie niespełniające specyfikacji Konwencjonalnych Commitów zostanie wprowadzone.
|
||||
Po prostu znaczy to, że będzie pominięty przez narzędzia bazujące na specyfikacji.
|
||||
|
||||
### Czy wszyscy moi kontrybutorzy muszą używać specyfikacji Konwencjonalnych Commitów?
|
||||
|
||||
Nie! Jeśli używasz trybu bazującego na spłaszczaniu historii dostarczeń, wtedy główni opiekunowie projektu mogą posprzątać wiadomości
|
||||
podczas dostarczania. Takie podejście nie narzuca żadnego obowiązku na osoby dostarczające od czasu do czasu. Powszechnym podejściem
|
||||
jest używanie automatycznego spłaszczania historii dostarczeń z prośby wciągnięcia (pull request) oraz wyświetlenie formularza osobie dostarczającej w celu wypełnienia wiadomości poprawną treścią.
|
||||
|
||||
## O twórcy
|
||||
|
||||
Specyfikacja Konwencjonalnych Commitów jest inspirowana oraz mocno bazuje na [Wytycznych Commitów Angulara](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
|
||||
|
||||
Pierwsza wersja tej specyfikacji została stworzona we współpracy z kilkoma kontrybutorami takich projektów jak:
|
||||
|
||||
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): zbiór narzędzi
|
||||
pozwalających na parsowanie konwencjonalnych commitów z historii `git`owych dostarczeń.
|
||||
* [unleash](https://github.com/netflix/unleash): narzędzie do automatyzacji wydawania oraz publikowania.
|
||||
* [lerna](https://github.com/lerna/lerna): narzędzie do zarządzania mono-repozytoriami, które wyrosło z projektu Babel.
|
||||
|
||||
## Projekty używające Konwencjonalnych Commitów
|
||||
|
||||
* [yargs](https://github.com/yargs/yargs): uwielbiany przez wszystkich, piracko stylizowany parser argumentów linii komend.
|
||||
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): kolekcja otwarto-źródłowych narzędzi oraz bibliotek do dodawania miar pokrycia kodu do Twoich testów jednostkowych
|
||||
* [standard-version](https://github.com/conventional-changelog/standard-version): Automatyczne zarządzanie wersjami oraz DZIENNIKIEM ZMIAN, używający nowego przycisku Spłaszcz na GitHubie oraz trybu pracy opartego o Konwencjonalne Commity.
|
||||
* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) oraz [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): Opcjonalny, uupełniający interfejs użytkownika ulepszający [Apereo uPortal](https://www.apereo.org/projects/uportal).
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_chcesz, aby Twój projekt znajdował się na tej liście?_ [stwórz pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencja
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
@ -1,162 +0,0 @@
|
||||
---
|
||||
title: 约定式提交 1.0.0-beta.2
|
||||
language: zh-Hans
|
||||
---
|
||||
|
||||
# 约定式提交 1.0.0-beta.2
|
||||
|
||||
## 概述
|
||||
|
||||
开源维护者在将特性分支合并入 `master` 时，可编写标准化的提交说明。
|
||||
|
||||
提交说明的结构如下所示：
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
<类型>[可选的作用域]: <描述>
|
||||
|
||||
[可选的正文]
|
||||
|
||||
[可选的脚注]
|
||||
```
|
||||
---
|
||||
|
||||
<br />
|
||||
提交说明包含了下面的结构化元素，以向类库使用者表明其意图：
|
||||
|
||||
1. **fix:** _类型_ 为 `fix` 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 [`PATCH`](http://semver.org/#summary) 相对应）。
|
||||
2. **feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应）。
|
||||
3. **BREAKING CHANGE:** 在可选的正文或脚注的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性变更（这和语义化版本中的 [`MAJOR`](http://semver.org/#summary) 相对应）。破坏性变更可以是任意 _类型_ 提交的一部分。对于 `fix:`、`feat:` 和 `chore:`，乃至更多其它的 _类型_ 而言，它都是有效的。
|
||||
4. 其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。
|
||||
|
||||
<br />
|
||||
可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 `feat(parser): adds ability to parse arrays.`
|
||||
|
||||
## 示例
|
||||
|
||||
### 包含了描述与正文内破坏性变更的提交说明
|
||||
```
|
||||
feat: allow provided config object to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||
```
|
||||
|
||||
### 不包含正文的提交说明
|
||||
```
|
||||
docs: correct spelling of CHANGELOG
|
||||
```
|
||||
|
||||
### 包含作用域的提交说明
|
||||
```
|
||||
feat(lang): added polish language
|
||||
```
|
||||
|
||||
### 为 fix 编写的提交说明，包含可选的 issue 编号
|
||||
```
|
||||
fix: minor typos in code
|
||||
|
||||
see the issue for details on the typos fixed
|
||||
|
||||
fixes issue #12
|
||||
```
|
||||
|
||||
## 介绍
|
||||
|
||||
在软件开发中，个人的经验是 bug 最常由应用间的边界引入。对单元测试而言，在所测试的交互处在开源维护者知识范围内时，它工作得很好。但在刻画社区里各种有趣而常在预料之外的使用场景时，它就显得比较糟糕了。
|
||||
|
||||
任何在升级新依赖 patch 版本后发现应用开始抛出稳定 500 错误流的人，都知道可读的提交历史（以及[理想条件下高质量维护的 CHANGELOG](http://keepachangelog.com/en/0.3.0/)）有多重要。
|
||||
|
||||
约定式的提交规范提议在提交说明的基础上，引入标准化的轻量约定。这个约定和 [SemVer](http://semver.org) 相吻合，要求开发者在提交信息中描述新特性、bug 修复和破坏性更新。
|
||||
|
||||
引入这一约定后，我们可以创建一种通用的语言，简化在项目边界之间调试的问题。
|
||||
|
||||
## 约定式提交规范
|
||||
|
||||
本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。
|
||||
|
||||
1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的名词组成，其后接冒号和空格。
|
||||
2. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
|
||||
3. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
|
||||
4. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
|
||||
5. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对代码变更的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
|
||||
6. 在简短描述之后，**可以**编写更长的提交正文，为代码变更提供额外的上下文信息。正文**必须**起始于描述字段结束的一个空行后。
|
||||
7. 在正文结束的一个空行后，**可以**编写脚注（如果正文缺失，可以编写在描述之后）。脚注**应当**为代码变更包含额外的 issue 引用信息（例如它所修复的 issue，类似 `Fixes #13` 等）。
|
||||
8. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
|
||||
9. 在 `BREAKING CHANGE: ` 之后**必须**提供描述，以描述对 API 的变更。例如 _BREAKING CHANGE: environment variables now take precedence over config files._
|
||||
10. 脚注**必须**只包含 `BREAKING CHANGE`、外部链接、issue 引用和其它元数据信息。
|
||||
11. 在提交说明中，**可以**使用 `feat` 和 `fix` 之外的类型。
|
||||
|
||||
## 为什么使用约定式提交
|
||||
|
||||
* 自动化生成 CHANGELOG。
|
||||
* 基于提交的类型，自动决定语义化的版本变更。
|
||||
* 向同事、公众与其他利益关系人传达变化的性质。
|
||||
* 触发构建和部署流程。
|
||||
* 让人们更容易地探索结构化的提交历史，降低贡献项目的难度。
|
||||
|
||||
## FAQ
|
||||
|
||||
### 如何处理初始开发阶段的提交说明？
|
||||
|
||||
我们建议你按照已发布的产品那样来处理。一般情况下即便是开发者同事，也*有人*使用你的软件。他们会希望知道诸如修复了什么、哪里不兼容等信息。
|
||||
|
||||
### 提交符合一或多种类型时该如何处理？
|
||||
|
||||
回退并尽可能创建多次提交。约定式提交的部分好处是能够促使我们做出更有组织的提交和 PR。
|
||||
|
||||
### 这不会阻碍快速的开发和迭代吗？
|
||||
|
||||
它阻碍的是以杂乱无章的方式快速前进。它帮助我们在横跨长时间周期、多个项目、多个贡献者时能够保持效率。
|
||||
|
||||
### 约定式提交会让开发者受限于提交的类型吗？
|
||||
|
||||
约定式提交鼓励我们更多地使用某些类型的提交，比如 fixes。除此之外，约定式提交的灵活性也允许你的团队使用自己的类型，并随着时间的推移更改这些类型。
|
||||
|
||||
### 这和 SemVer 有什么关联呢？
|
||||
|
||||
`fix` 类型提交应当对应到 `PATCH` 版本。`feat` 类型提交应该对应到 `MINOR` 版本。带有 `BREAKING CHANGE` 的提交不管类型如何，都应该对应到 `MAJOR` 版本。
|
||||
|
||||
### 我对约定式提交做了形如 `@jameswomack/conventional-commit-spec` 的扩展，该如何版本化管理这些扩展呢？
|
||||
|
||||
我们推荐使用 SemVer 来发布你对于这个规范的扩展（并鼓励你创建这些扩展！）
|
||||
|
||||
### 如果我不小心使用了错误的提交类型，该怎么办呢？
|
||||
|
||||
#### 当你使用了在规范中但错误的类型时，如将 `feat` 写成了 `fix`
|
||||
|
||||
在合并或发布这个错误之前，我们建议使用 `git rebase -i` 来编辑提交历史。而在发布之后，根据你使用的工具和流程不同，会有不同的清理方案。
|
||||
|
||||
#### 当使用了*不*在规范中的类型时，如将 `feat` 写成了 `feet`
|
||||
|
||||
在最坏的场景下，即便提交没有满足约定式提交的规范，也不是世界的终结。这只意味着这个提交会被基于规范的工具错过而已。
|
||||
|
||||
### 所有的贡献者都需要使用约定式提交规范吗？
|
||||
|
||||
并不！如果你使用基于 squash 的 Git 工作流，主管维护者可以在合并时清理提交信息——这不会对普通提交者产生额外的负担。有种常见的工作流是让 git 系统自动从 pull request 中 squash 出提交，向主管维护者提供表单，来在合并时输入合适的 git 提交信息。
|
||||
|
||||
## 关于
|
||||
|
||||
约定式提交规范受到了 [Angular 提交准则](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit)的启发，并在很大程度上以其为依据。
|
||||
|
||||
该规范的首个草案来自下面这些项目中若干贡献者们的协作：
|
||||
|
||||
|
||||
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)：一套从 git 历史中解析出约定式提交说明的工具。
|
||||
* [unleash](https://github.com/netflix/unleash)：一个用于自动化软件发行和发布生命周期的工具。
|
||||
* [lerna](https://github.com/lerna/lerna)：一个用于管理宏仓库的工具，源自 Babel 项目。
|
||||
|
||||
## 使用约定式提交的项目
|
||||
|
||||
* [yargs](https://github.com/yargs/yargs)：广受欢迎的命令行参数解析器。
|
||||
* [istanbuljs](https://github.com/istanbuljs/istanbuljs)：一套为 JavaScript 测试生成测试覆盖率的开源工具和类库。
|
||||
* [standard-version](https://github.com/conventional-changelog/standard-version) 基于 GitHub 的新 squash 按钮与推荐的约定式提交工作流，自动管理版本和 CHANGELOG。
|
||||
* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) 和 [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame)：用于增强 [Apereo uPortal](https://www.apereo.org/projects/uportal) 的可选用户界面。
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_想让你的项目出现在上面吗？_[提交 pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls) 吧。
|
||||
|
||||
## 许可
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
0
layouts/.gitkeep
Normal file
0
layouts/.gitkeep
Normal file
@ -1,3 +0,0 @@
|
||||
#!/bin/sh
|
||||
|
||||
bundle install
|
||||
@ -1,6 +0,0 @@
|
||||
#!/bin/sh
|
||||
|
||||
set -e
|
||||
|
||||
bundle exec jekyll build --config _config.yml,_config_local.yml
|
||||
bundle exec htmlproofer _site --check-html --disable-external
|
||||
@ -1,3 +0,0 @@
|
||||
#!/bin/sh
|
||||
|
||||
bundle exec jekyll serve --config _config.yml,_config_local.yml
|
||||
0
static/.gitkeep
Normal file
0
static/.gitkeep
Normal file
15
themes/conventional-commits/.editorconfig
Normal file
15
themes/conventional-commits/.editorconfig
Normal file
@ -0,0 +1,15 @@
|
||||
# http://editorconfig.org
|
||||
|
||||
root = true
|
||||
|
||||
[*]
|
||||
charset = utf-8
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
end_of_line = lf
|
||||
insert_final_newline = true
|
||||
trim_trailing_whitespace = true
|
||||
|
||||
[*.md]
|
||||
insert_final_newline = false
|
||||
trim_trailing_whitespace = false
|
||||
65
themes/conventional-commits/.gitignore
vendored
Normal file
65
themes/conventional-commits/.gitignore
vendored
Normal file
@ -0,0 +1,65 @@
|
||||
.idea
|
||||
.DS_Store
|
||||
package-lock.json
|
||||
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
|
||||
# Runtime data
|
||||
pids
|
||||
*.pid
|
||||
*.seed
|
||||
*.pid.lock
|
||||
|
||||
# Directory for instrumented libs generated by jscoverage/JSCover
|
||||
lib-cov
|
||||
|
||||
# Coverage directory used by tools like istanbul
|
||||
coverage
|
||||
|
||||
# nyc test coverage
|
||||
.nyc_output
|
||||
|
||||
# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
|
||||
.grunt
|
||||
|
||||
# Bower dependency directory (https://bower.io/)
|
||||
bower_components
|
||||
|
||||
# node-waf configuration
|
||||
.lock-wscript
|
||||
|
||||
# Compiled binary addons (https://nodejs.org/api/addons.html)
|
||||
build/Release
|
||||
|
||||
# Dependency directories
|
||||
node_modules/
|
||||
jspm_packages/
|
||||
|
||||
# TypeScript v1 declaration files
|
||||
typings/
|
||||
|
||||
# Optional npm cache directory
|
||||
.npm
|
||||
|
||||
# Optional eslint cache
|
||||
.eslintcache
|
||||
|
||||
# Optional REPL history
|
||||
.node_repl_history
|
||||
|
||||
# Output of 'npm pack'
|
||||
*.tgz
|
||||
|
||||
# Yarn Integrity file
|
||||
.yarn-integrity
|
||||
|
||||
# dotenv environment variables file
|
||||
.env
|
||||
|
||||
# next.js build output
|
||||
.next
|
||||
20
themes/conventional-commits/LICENSE
Normal file
20
themes/conventional-commits/LICENSE
Normal file
@ -0,0 +1,20 @@
|
||||
The MIT License (MIT)
|
||||
|
||||
Copyright (c) 2018 YOUR_NAME_HERE
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of
|
||||
this software and associated documentation files (the "Software"), to deal in
|
||||
the Software without restriction, including without limitation the rights to
|
||||
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
|
||||
the Software, and to permit persons to whom the Software is furnished to do so,
|
||||
subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
|
||||
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
|
||||
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
|
||||
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
||||
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
69
themes/conventional-commits/README.md
Normal file
69
themes/conventional-commits/README.md
Normal file
@ -0,0 +1,69 @@
|
||||
# hugo conventional commits theme
|
||||
Copy hugo-conventional-commits-theme inside your my-hugo-site/theme
|
||||
|
||||
## config.yaml example
|
||||
All config params are optionals.
|
||||
```yaml
|
||||
baseURL: 'http://conventional-commits.org/'
|
||||
languageCode: en-us
|
||||
title: Conventional Commits
|
||||
theme: conventional-commits
|
||||
|
||||
# Language
|
||||
defaultContentLanguageInSubdir: true
|
||||
defaultContentLanguage: "en"
|
||||
languages:
|
||||
en:
|
||||
weight: 1
|
||||
languageName: "English"
|
||||
it:
|
||||
weight: 2
|
||||
languageName: "Italian"
|
||||
|
||||
# Content
|
||||
params:
|
||||
versions:
|
||||
current: 1.0.0-beta.2
|
||||
list:
|
||||
- label: 1.0.0-beta
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
- label: 1.0.0-beta.1
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
- label: 1.0.0-beta.2
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
|
||||
welcome:
|
||||
description: A specification made for write standardized and useful commit messages
|
||||
image: 'https://path-to-image'
|
||||
actions:
|
||||
- label: Read the specs
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
- label: GitHub
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
|
||||
license:
|
||||
title: License
|
||||
action:
|
||||
label: Creative Commons - CC BY 3.0
|
||||
url: 'https://creativecommons.org/licenses/by/3.0/'
|
||||
|
||||
footer:
|
||||
logos:
|
||||
- name: github
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
```
|
||||
|
||||
## Apply theme changes
|
||||
Development script
|
||||
```ssh
|
||||
npm run start
|
||||
```
|
||||
|
||||
Production script
|
||||
```ssh
|
||||
npm run build
|
||||
```
|
||||
|
||||
## Shortcodes
|
||||
* banner-image
|
||||
* src (optional) | default: static/img/git-flow.png
|
||||
2
themes/conventional-commits/archetypes/default.md
Normal file
2
themes/conventional-commits/archetypes/default.md
Normal file
@ -0,0 +1,2 @@
|
||||
+++
|
||||
+++
|
||||
8
themes/conventional-commits/layouts/404.html
Normal file
8
themes/conventional-commits/layouts/404.html
Normal file
@ -0,0 +1,8 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<body>
|
||||
<main>
|
||||
404
|
||||
</main>
|
||||
</body>
|
||||
</html>
|
||||
15
themes/conventional-commits/layouts/_default/single.html
Normal file
15
themes/conventional-commits/layouts/_default/single.html
Normal file
@ -0,0 +1,15 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
{{- partial "head.html" . -}}
|
||||
<body class="conventional-commits--loading">
|
||||
{{- partial "header.html" . -}}
|
||||
{{- partial "welcome.html" . -}}
|
||||
<main>
|
||||
<article class="container markdown-body">
|
||||
{{.Content}}
|
||||
</article>
|
||||
</main>
|
||||
{{- partial "footer.html" . -}}
|
||||
{{- partial "scripts.html" . -}}
|
||||
</body>
|
||||
</html>
|
||||
21
themes/conventional-commits/layouts/partials/footer.html
Normal file
21
themes/conventional-commits/layouts/partials/footer.html
Normal file
@ -0,0 +1,21 @@
|
||||
<footer class="footer">
|
||||
<div class="container">
|
||||
{{ if .Site.Params.License }}
|
||||
<div class="footer__license">
|
||||
{{ if .Site.Params.License.Title }}
|
||||
<p>{{ .Site.Params.License.Title }}</p>
|
||||
{{ end }}
|
||||
{{ if .Site.Params.License.Action }}
|
||||
<a href="{{.Site.Params.License.Action.Url}}" target="_blank">{{.Site.Params.License.Action.Label}}</a>
|
||||
{{ end }}
|
||||
</div>
|
||||
{{ end }}
|
||||
<div class="footer__logos">
|
||||
{{ range .Site.Params.Footer.Logos }}
|
||||
{{ if .name }}
|
||||
<a class="footer__logo" href="{{.url}}">{{ (partial (printf "%s%v%s" "svg-" .name ".html") .) }}</a>
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
</div>
|
||||
</div>
|
||||
</footer>
|
||||
2
themes/conventional-commits/layouts/partials/head.html
Normal file
2
themes/conventional-commits/layouts/partials/head.html
Normal file
@ -0,0 +1,2 @@
|
||||
<meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1,maximum-scale=1,user-scalable=no">
|
||||
<link rel="stylesheet" href="{{ .Site.BaseURL }}css/style.css">
|
||||
24
themes/conventional-commits/layouts/partials/header.html
Normal file
24
themes/conventional-commits/layouts/partials/header.html
Normal file
@ -0,0 +1,24 @@
|
||||
<header class="header">
|
||||
<div class="container">
|
||||
<a href="/"><div class="logo"></div></a>
|
||||
<ul class="header__menu">
|
||||
<li class="header__menu-item dropdown">
|
||||
<button class="dropdown__label">Versions</button>
|
||||
<ul class="dropdown__options">
|
||||
{{ range .Site.Params.Versions.List }}
|
||||
<li class="dropdown__option"><a href="/{{ $.Site.Language }}/{{ . }}">{{ . }}</a></li>
|
||||
{{ end }}
|
||||
</ul>
|
||||
</li>
|
||||
<li class="header__menu-item dropdown">
|
||||
<button class="dropdown__label">Languages</button>
|
||||
<ul class="dropdown__options">
|
||||
{{ .Site.Home.AllTranslations }}
|
||||
{{ range .Site.Home.AllTranslations }}
|
||||
<li class="dropdown__option"><a href="{{ .Permalink }}">{{ .Language.LanguageName }}</a></li>
|
||||
{{ end }}
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</header>
|
||||
@ -0,0 +1 @@
|
||||
<script src="{{ .Site.BaseURL }}js/bundle.js"></script>
|
||||
@ -0,0 +1,8 @@
|
||||
<svg class="github" viewBox="0 0 128 128">
|
||||
<path
|
||||
fill-rule="evenodd"
|
||||
clip-rule="evenodd"
|
||||
d="M64 5.103c-33.347 0-60.388 27.035-60.388 60.388 0 26.682 17.303 49.317 41.297 57.303 3.017.56 4.125-1.31 4.125-2.905 0-1.44-.056-6.197-.082-11.243-16.8 3.653-20.345-7.125-20.345-7.125-2.747-6.98-6.705-8.836-6.705-8.836-5.48-3.748.413-3.67.413-3.67 6.063.425 9.257 6.223 9.257 6.223 5.386 9.23 14.127 6.562 17.573 5.02.542-3.903 2.107-6.568 3.834-8.076-13.413-1.525-27.514-6.704-27.514-29.843 0-6.593 2.36-11.98 6.223-16.21-.628-1.52-2.695-7.662.584-15.98 0 0 5.07-1.623 16.61 6.19C53.7 35 58.867 34.327 64 34.304c5.13.023 10.3.694 15.127 2.033 11.526-7.813 16.59-6.19 16.59-6.19 3.287 8.317 1.22 14.46.593 15.98 3.872 4.23 6.215 9.617 6.215 16.21 0 23.194-14.127 28.3-27.574 29.796 2.167 1.874 4.097 5.55 4.097 11.183 0 8.08-.07 14.583-.07 16.572 0 1.607 1.088 3.49 4.148 2.897 23.98-7.994 41.263-30.622 41.263-57.294C124.388 32.14 97.35 5.104 64 5.104z"></path>
|
||||
<path
|
||||
d="M26.484 91.806c-.133.3-.605.39-1.035.185-.44-.196-.685-.605-.543-.906.13-.31.603-.395 1.04-.188.44.197.69.61.537.91zm-.743-.55M28.93 94.535c-.287.267-.85.143-1.232-.28-.396-.42-.47-.983-.177-1.254.298-.266.844-.14 1.24.28.394.426.472.984.17 1.255zm-.575-.618M31.312 98.012c-.37.258-.976.017-1.35-.52-.37-.538-.37-1.183.01-1.44.373-.258.97-.025 1.35.507.368.545.368 1.19-.01 1.452zm0 0M34.573 101.373c-.33.365-1.036.267-1.552-.23-.527-.487-.674-1.18-.343-1.544.336-.366 1.045-.264 1.564.23.527.486.686 1.18.333 1.543zm0 0M39.073 103.324c-.147.473-.825.688-1.51.486-.683-.207-1.13-.76-.99-1.238.14-.477.823-.7 1.512-.485.683.206 1.13.756.988 1.237zm0 0M44.016 103.685c.017.498-.563.91-1.28.92-.723.017-1.308-.387-1.315-.877 0-.503.568-.91 1.29-.924.717-.013 1.306.387 1.306.88zm0 0M48.614 102.903c.086.485-.413.984-1.126 1.117-.7.13-1.35-.172-1.44-.653-.086-.498.422-.997 1.122-1.126.714-.123 1.354.17 1.444.663zm0 0"></path>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 1.9 KiB |
16
themes/conventional-commits/layouts/partials/welcome.html
Normal file
16
themes/conventional-commits/layouts/partials/welcome.html
Normal file
@ -0,0 +1,16 @@
|
||||
<section class="welcome">
|
||||
<div class="container">
|
||||
<h1 class="welcome__title">{{.Param "Title"}}</h1>
|
||||
<p class="welcome__description">{{.Param "Description"}}</p>
|
||||
{{ if .Param "Actions" }}
|
||||
<div class="welcome__actions">
|
||||
{{ range .Param "Actions" }}
|
||||
<a class="welcome__action" href="{{.url}}">{{.label}}</a>
|
||||
{{ end }}
|
||||
</div>
|
||||
{{ end }}
|
||||
<figure class="welcome__image">
|
||||
<img src='{{default "/img/git-flow--welcome.png"}}'>
|
||||
</figure>
|
||||
</div>
|
||||
</section>
|
||||
@ -0,0 +1,3 @@
|
||||
<figure class="banner-image">
|
||||
<img class="banner-image__picture" src='{{.Get "src" | default "/img/git-flow.png"}}'>
|
||||
</figure>
|
||||
7311
themes/conventional-commits/package-lock.json
generated
Normal file
7311
themes/conventional-commits/package-lock.json
generated
Normal file
File diff suppressed because it is too large
Load Diff
33
themes/conventional-commits/package.json
Normal file
33
themes/conventional-commits/package.json
Normal file
@ -0,0 +1,33 @@
|
||||
{
|
||||
"name": "hugo-conventional-commits-theme",
|
||||
"version": "1.0.0",
|
||||
"description": "",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"start": "npm run css:watch & npm run js:watch",
|
||||
"css": "node-sass ./static/css/scss/style.scss -o ./static/css",
|
||||
"css:watch": "npm run css -- -w",
|
||||
"css:autoprefixer": "postcss --no-map --use autoprefixer -o ./static/css/style.css ./static/css/style.css",
|
||||
"css:nano": "postcss --no-map --use cssnano -o ./static/css/style.css ./static/css/style.css",
|
||||
"css:build": "npm run css && npm run css:autoprefixer && npm run css:nano",
|
||||
"js": "webpack --mode=development ./static/js/index.js -o ./static/js/bundle.js",
|
||||
"js:watch": "npm run js -- --watch",
|
||||
"js:build": "webpack --mode=production ./static/js/index.js -o ./static/js/bundle.js",
|
||||
"build": "npm run css:build && npm run js:build"
|
||||
},
|
||||
"author": "",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"anchor-js": "^4.1.1",
|
||||
"github-markdown-css": "^2.10.0"
|
||||
},
|
||||
"devDependencies": {
|
||||
"autoprefixer": "^9.1.3",
|
||||
"cssnano": "^4.1.0",
|
||||
"node-sass": "^4.9.3",
|
||||
"postcss": "^7.0.2",
|
||||
"postcss-cli": "^6.0.0",
|
||||
"webpack": "^4.17.1",
|
||||
"webpack-cli": "^3.1.0"
|
||||
}
|
||||
}
|
||||
0
themes/conventional-commits/static/css/index.css
Normal file
0
themes/conventional-commits/static/css/index.css
Normal file
@ -0,0 +1,11 @@
|
||||
@import "./../abstracts/variables";
|
||||
|
||||
|
||||
@function get-color-accessible-for-background($color) {
|
||||
@if (lightness( $color ) > 50) {
|
||||
@return darken($color, 60%)
|
||||
}
|
||||
@else {
|
||||
@return lighten($color, 60%)
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,29 @@
|
||||
@import "variables";
|
||||
|
||||
@mixin tablet {
|
||||
@media (min-width: #{$tablet-width}) and (max-width: #{$desktop-width - 1px}) {
|
||||
@content;
|
||||
}
|
||||
}
|
||||
|
||||
@mixin desktop {
|
||||
@media (min-width: #{$desktop-width}) {
|
||||
@content;
|
||||
}
|
||||
}
|
||||
|
||||
@mixin gradient-primary($deg: 45deg) {
|
||||
background: linear-gradient($deg, $color-primary 0%, $color-primary-light 100%);
|
||||
}
|
||||
|
||||
@mixin dropdown-animation-visible {
|
||||
visibility: visible;
|
||||
opacity: 1;
|
||||
transform: translate(-50%, $dropdown-options-space-from-label);
|
||||
}
|
||||
|
||||
@mixin dropdown-animation-hidden {
|
||||
visibility: hidden;
|
||||
opacity: 0;
|
||||
transform: translate(-50%, 0);
|
||||
}
|
||||
@ -0,0 +1,40 @@
|
||||
$color-primary: #FE5196;
|
||||
$color-primary-light: #F77062;
|
||||
$color-neutral-light: #FFF;
|
||||
$color-neutral-dark: #000;
|
||||
|
||||
$color-primary-heading: #FA6673;
|
||||
|
||||
$gap-sm: 8px;
|
||||
$gap-md: 24px;
|
||||
$gap-lg: 48px;
|
||||
|
||||
$radius-md: 4px;
|
||||
$radius-lg: 8px;
|
||||
|
||||
$shadow-soft: 0 2px 10px 0 rgba(0, 0, 0, .03), 0 2px 20px 10px rgba(0, 0, 0, 0.02);
|
||||
|
||||
$tablet-width: 768px;
|
||||
$desktop-width: 1024px;
|
||||
|
||||
$header-height: 56px;
|
||||
$footer-logo-size: 24px;
|
||||
|
||||
$welcome-min-height: 450px;
|
||||
$welcome-height: 100vh;
|
||||
$welcome-action-color: $color-neutral-light;
|
||||
|
||||
$main-background: $color-neutral-light;
|
||||
$article-background: $color-neutral-light;
|
||||
$article-offset-top: -$header-height + -$gap-sm;
|
||||
|
||||
$dropdown-padding: 12px 16px;
|
||||
$dropdown-border-radius: $radius-md;
|
||||
$dropdown-animation-timing: .4s;
|
||||
$dropdown-label-background-color: transparent;
|
||||
$dropdown-arrow-size: 10px;
|
||||
$dropdown-options-background-color: $color-neutral-light;
|
||||
$dropdown-options-space-from-label: $gap-sm;
|
||||
$dropdown-option-border-bottom-color: rgba($color-neutral-dark, .04);
|
||||
|
||||
$banner-image-height: 300px;
|
||||
@ -0,0 +1,4 @@
|
||||
@import './variables';
|
||||
@import './mixins';
|
||||
@import './functions';
|
||||
|
||||
51
themes/conventional-commits/static/css/scss/base/_base.scss
Normal file
51
themes/conventional-commits/static/css/scss/base/_base.scss
Normal file
@ -0,0 +1,51 @@
|
||||
@import "./../abstracts/index";
|
||||
|
||||
* {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
box-sizing: border-box;
|
||||
-webkit-font-smoothing: antialiased;
|
||||
-moz-osx-font-smoothing: grayscale;
|
||||
-webkit-tap-highlight-color: rgba($color-neutral-dark, 0);
|
||||
}
|
||||
|
||||
body {
|
||||
position: relative;
|
||||
min-height: 100vh;
|
||||
font: 16px Helvetica, sans-serif;
|
||||
}
|
||||
|
||||
.container {
|
||||
width: 100%;
|
||||
max-width: $desktop-width;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
padding-left: $gap-md;
|
||||
padding-right: $gap-md;
|
||||
}
|
||||
|
||||
main {
|
||||
background-color: $main-background;
|
||||
}
|
||||
|
||||
article {
|
||||
background-color: $article-background;
|
||||
transform: translateY($article-offset-top);
|
||||
padding-top: $gap-md;
|
||||
padding-bottom: $gap-md;
|
||||
border-radius: $radius-lg;
|
||||
min-height: 50vh;
|
||||
box-shadow: $shadow-soft;
|
||||
}
|
||||
|
||||
@include desktop {
|
||||
.container {
|
||||
padding-left: $gap-lg;
|
||||
padding-right: $gap-lg;
|
||||
}
|
||||
|
||||
article {
|
||||
padding-top: $gap-lg - $gap-sm;
|
||||
padding-bottom: $gap-lg - $gap-sm;
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,19 @@
|
||||
@import "./../abstracts/index";
|
||||
|
||||
.banner-image {
|
||||
width: 100%;
|
||||
border-radius: $radius-md;
|
||||
margin: $gap-lg 0;
|
||||
box-shadow: $shadow-soft;
|
||||
@include gradient-primary(14deg);
|
||||
|
||||
img.banner-image__picture {
|
||||
display: block;
|
||||
width: 100%;
|
||||
min-height: 100px;
|
||||
max-height: $banner-image-height;
|
||||
object-fit: contain;
|
||||
margin: auto;
|
||||
background-color: transparent;
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,107 @@
|
||||
@import "./../abstracts/index";
|
||||
|
||||
@keyframes show {
|
||||
from {
|
||||
@include dropdown-animation-hidden;
|
||||
}
|
||||
to {
|
||||
@include dropdown-animation-visible;
|
||||
}
|
||||
}
|
||||
|
||||
@keyframes hide {
|
||||
from {
|
||||
@include dropdown-animation-visible;
|
||||
}
|
||||
to {
|
||||
@include dropdown-animation-hidden;
|
||||
}
|
||||
}
|
||||
|
||||
.dropdown {
|
||||
position: relative;
|
||||
min-width: 110px;
|
||||
|
||||
&__label {
|
||||
display: block;
|
||||
width: 100%;
|
||||
appearance: none;
|
||||
border: none;
|
||||
outline: none;
|
||||
font-size: inherit;
|
||||
color: inherit;
|
||||
text-decoration: inherit;
|
||||
text-transform: inherit;
|
||||
text-align: center;
|
||||
padding: $dropdown-padding;
|
||||
background-color: $dropdown-label-background-color;
|
||||
border-radius: $dropdown-border-radius;
|
||||
&:after {
|
||||
display: none;
|
||||
content: '';
|
||||
width: 100%;
|
||||
height: $dropdown-options-space-from-label * 1.5;
|
||||
position: absolute;
|
||||
top: 100%;
|
||||
left: 0;
|
||||
background-color: transparent;
|
||||
}
|
||||
}
|
||||
|
||||
&__options {
|
||||
visibility: visible;
|
||||
min-width: 100%;
|
||||
position: absolute;
|
||||
top: 100%;
|
||||
left: 50%;
|
||||
transform: translate(-50%, 0);
|
||||
list-style: none;
|
||||
background-color: $dropdown-options-background-color;
|
||||
border-radius: $dropdown-border-radius;
|
||||
box-shadow: $shadow-soft;
|
||||
animation: hide $dropdown-animation-timing/2 ease forwards;
|
||||
&:before {
|
||||
content: '';
|
||||
width: 0;
|
||||
height: 0;
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 50%;
|
||||
border-style: solid;
|
||||
border-width: 0 $dropdown-arrow-size ($dropdown-arrow-size/2) $dropdown-arrow-size;
|
||||
border-color: transparent transparent $dropdown-options-background-color transparent;
|
||||
transform: translate(-50%, -100%);
|
||||
}
|
||||
}
|
||||
|
||||
&__option {
|
||||
a {
|
||||
display: block;
|
||||
padding: $dropdown-padding;
|
||||
color: rgba(black, .6);
|
||||
text-decoration: none;
|
||||
border-bottom: 1px solid $dropdown-option-border-bottom-color;
|
||||
transition: background-color .3s ease, color .3s ease;
|
||||
text-transform: none;
|
||||
font-weight: normal;
|
||||
&:hover,
|
||||
&:focus {
|
||||
color: $color-primary;
|
||||
background-color: rgba($color-neutral-dark, .025);
|
||||
}
|
||||
}
|
||||
&:last-child a {
|
||||
border-bottom: none;
|
||||
}
|
||||
}
|
||||
|
||||
&:hover &__label:after, &:hover &__options,
|
||||
&:focus &__label:after, &:focus &__options {
|
||||
display: block;
|
||||
}
|
||||
|
||||
&:hover &__options,
|
||||
&:focus &__options {
|
||||
animation: show $dropdown-animation-timing ease forwards;
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,35 @@
|
||||
@import "./../abstracts/index";
|
||||
|
||||
.footer {
|
||||
margin: ($article-offset-top + ($gap-md*3)) 0 ($gap-md*3);
|
||||
|
||||
.container {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
}
|
||||
|
||||
&__license {
|
||||
margin-right: auto;
|
||||
a {
|
||||
font-size: .7em;
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
&:hover {
|
||||
text-decoration: underline;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
&__logos {
|
||||
margin-left: auto;
|
||||
}
|
||||
|
||||
&__logo {
|
||||
display: flex;
|
||||
}
|
||||
|
||||
.github {
|
||||
width: $footer-logo-size;
|
||||
height: $footer-logo-size;
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,40 @@
|
||||
@import "./../abstracts/index";
|
||||
|
||||
.header {
|
||||
position: absolute;
|
||||
z-index: 10;
|
||||
top: 12px;
|
||||
left: 0;
|
||||
width: 100%;
|
||||
|
||||
.container {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: space-between;
|
||||
height: $header-height;
|
||||
font-size: .8em;
|
||||
font-weight: bold;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
.logo {
|
||||
width: 30px;
|
||||
height: 30px;
|
||||
background-color: transparent;
|
||||
border: 2px solid #FFF;
|
||||
border-radius: 50%;
|
||||
}
|
||||
|
||||
&__menu {
|
||||
display: flex;
|
||||
color: $color-neutral-light;
|
||||
list-style: none;
|
||||
}
|
||||
|
||||
&__menu-item {
|
||||
margin-right: $gap-sm;
|
||||
&:last-child {
|
||||
margin-right: 0;
|
||||
}
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,80 @@
|
||||
@import "./../abstracts/index";
|
||||
|
||||
.welcome {
|
||||
position: relative;
|
||||
z-index: 0;
|
||||
background: $color-primary;
|
||||
@include gradient-primary();
|
||||
|
||||
.container {
|
||||
position: relative;
|
||||
z-index: 2;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: center;
|
||||
height: $welcome-height;
|
||||
min-height: $welcome-min-height;
|
||||
color: $color-neutral-light;
|
||||
}
|
||||
|
||||
&__title {
|
||||
font-size: 3em;
|
||||
margin-bottom: $gap-sm;
|
||||
@include desktop {
|
||||
font-size: 3.6em;
|
||||
}
|
||||
}
|
||||
|
||||
&__description {
|
||||
font-size: 18px;
|
||||
}
|
||||
|
||||
&__actions {
|
||||
display: flex;
|
||||
margin-top: ($gap-lg * 3)/2;
|
||||
}
|
||||
|
||||
&__action {
|
||||
padding: 12px 16px;
|
||||
border-radius: 50px;
|
||||
text-decoration: none;
|
||||
color: $welcome-action-color;
|
||||
border: 1px solid $welcome-action-color;
|
||||
margin-right: $gap-md;
|
||||
transition: background-color .3s ease, color .3s ease;
|
||||
&:last-child {
|
||||
margin-right: 0;
|
||||
}
|
||||
&:hover {
|
||||
background-color: $welcome-action-color;
|
||||
color: get-color-accessible-for-background($welcome-action-color)
|
||||
}
|
||||
}
|
||||
|
||||
&__image {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
@include desktop {
|
||||
.welcome__image {
|
||||
display: flex;
|
||||
justify-content: center;
|
||||
align-items: center;
|
||||
z-index: -1;
|
||||
position: absolute;
|
||||
top: 50%;
|
||||
right: 0;
|
||||
height: 70%;
|
||||
width: 24%;
|
||||
overflow: hidden;
|
||||
transform: translate(0, -50%);
|
||||
img {
|
||||
display: block;
|
||||
margin: auto;
|
||||
max-width: 200px;
|
||||
max-height: 100%;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
9
themes/conventional-commits/static/css/scss/style.scss
Normal file
9
themes/conventional-commits/static/css/scss/style.scss
Normal file
@ -0,0 +1,9 @@
|
||||
@import 'base/base';
|
||||
@import 'layout/header';
|
||||
@import 'layout/footer';
|
||||
@import 'layout/welcome';
|
||||
@import "components/dropdown";
|
||||
@import "components/banner-image";
|
||||
@import "themes/markdown";
|
||||
@import "themes/conventional-commits";
|
||||
@import "vendors/github-markdown-css";
|
||||
@ -0,0 +1,6 @@
|
||||
.conventional-commits--loading {
|
||||
.dropdown__options {
|
||||
height: 0 !important;
|
||||
box-shadow: none !important;
|
||||
}
|
||||
}
|
||||
@ -0,0 +1,14 @@
|
||||
@import "./../abstracts/index";
|
||||
|
||||
main article.markdown-body {
|
||||
h1{
|
||||
font-size: 2.3em;
|
||||
}
|
||||
h1, h2, h3, h4, h5, h6, a {
|
||||
font-weight: bold;
|
||||
color: $color-primary-heading;
|
||||
}
|
||||
a.anchorjs-link:hover {
|
||||
text-decoration: none;
|
||||
}
|
||||
}
|
||||
1
themes/conventional-commits/static/css/scss/vendors/github-markdown-css.scss
vendored
Normal file
1
themes/conventional-commits/static/css/scss/vendors/github-markdown-css.scss
vendored
Normal file
@ -0,0 +1 @@
|
||||
@import "./../../../../node_modules/github-markdown-css/github-markdown";
|
||||
1
themes/conventional-commits/static/css/style.css
Normal file
1
themes/conventional-commits/static/css/style.css
Normal file
File diff suppressed because one or more lines are too long
1
themes/conventional-commits/static/css/style.min.css
vendored
Normal file
1
themes/conventional-commits/static/css/style.min.css
vendored
Normal file
File diff suppressed because one or more lines are too long
BIN
themes/conventional-commits/static/img/git-flow--welcome.png
Normal file
BIN
themes/conventional-commits/static/img/git-flow--welcome.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
themes/conventional-commits/static/img/git-flow.png
Normal file
BIN
themes/conventional-commits/static/img/git-flow.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 220 KiB |
343
themes/conventional-commits/static/img/git-flow.svg
Normal file
343
themes/conventional-commits/static/img/git-flow.svg
Normal file
@ -0,0 +1,343 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<svg width="1123px" height="265px" viewBox="0 0 1123 265" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<!-- Generator: Sketch 51.2 (57519) - http://www.bohemiancoding.com/sketch -->
|
||||
<title>Flow</title>
|
||||
<desc>Created with Sketch.</desc>
|
||||
<defs>
|
||||
<linearGradient x1="50%" y1="2.45438945%" x2="50%" y2="100%" id="linearGradient-1">
|
||||
<stop stop-color="#FFFFFF" stop-opacity="0" offset="0%"></stop>
|
||||
<stop stop-color="#FFFFFF" offset="8.09925939%"></stop>
|
||||
<stop stop-color="#FFFFFF" offset="91.9526734%"></stop>
|
||||
<stop stop-color="#FFFFFF" stop-opacity="0" offset="100%"></stop>
|
||||
</linearGradient>
|
||||
<linearGradient x1="50%" y1="2.45438945%" x2="50%" y2="74.6279632%" id="linearGradient-2">
|
||||
<stop stop-color="#FFFFFF" stop-opacity="0" offset="0%"></stop>
|
||||
<stop stop-color="#FFFFFF" offset="8.09925939%"></stop>
|
||||
<stop stop-color="#FFFFFF" offset="46.0169798%"></stop>
|
||||
<stop stop-color="#FFFFFF" offset="85.5762283%"></stop>
|
||||
<stop stop-color="#FFFFFF" stop-opacity="0" offset="89.0625%"></stop>
|
||||
</linearGradient>
|
||||
<circle id="path-3" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-4">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-5">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-6" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-7">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-8">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-9" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-10">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-11">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-12" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-13">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-14">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-15" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-16">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-17">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-18" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-19">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-20">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-21" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-22">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-23">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-24" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-25">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-26">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-27" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-28">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-29">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-30" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-31">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-32">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-33" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-34">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-35">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-36" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-37">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-38">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<path d="M156,796 L156,729.922037 L156,648.3425 C156,595.284487 156,552.010388 156,518.520202 C156,468.284924 107.653356,497.414672 107.653356,435.489593 C107.653356,394.206207 107.653356,373.710704 107.653356,374.003084 C47.8844521,374.001028 18,374 18,374" id="path-39"></path>
|
||||
<filter x="-2.2%" y="-0.7%" width="104.3%" height="101.4%" filterUnits="objectBoundingBox" id="filter-40">
|
||||
<feMorphology radius="1.5" operator="dilate" in="SourceAlpha" result="shadowSpreadOuter1"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowSpreadOuter1" result="shadowOffsetOuter1"></feOffset>
|
||||
<feMorphology radius="1.5" operator="erode" in="SourceAlpha" result="shadowInner"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowInner" result="shadowInner"></feOffset>
|
||||
<feComposite in="shadowOffsetOuter1" in2="shadowInner" operator="out" result="shadowOffsetOuter1"></feComposite>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<path d="M155,647 C207.897477,647 189.438774,594.000253 248,594" id="path-41"></path>
|
||||
<filter x="-3.2%" y="-5.7%" width="106.5%" height="111.3%" filterUnits="objectBoundingBox" id="filter-42">
|
||||
<feMorphology radius="1.5" operator="dilate" in="SourceAlpha" result="shadowSpreadOuter1"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowSpreadOuter1" result="shadowOffsetOuter1"></feOffset>
|
||||
<feMorphology radius="1.5" operator="erode" in="SourceAlpha" result="shadowInner"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowInner" result="shadowInner"></feOffset>
|
||||
<feComposite in="shadowOffsetOuter1" in2="shadowInner" operator="out" result="shadowOffsetOuter1"></feComposite>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<path d="M61,796 C61,709.221766 18,783.795496 18,700" id="path-43"></path>
|
||||
<filter x="-7.0%" y="-3.1%" width="114.0%" height="106.2%" filterUnits="objectBoundingBox" id="filter-44">
|
||||
<feMorphology radius="1.5" operator="dilate" in="SourceAlpha" result="shadowSpreadOuter1"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowSpreadOuter1" result="shadowOffsetOuter1"></feOffset>
|
||||
<feMorphology radius="1.5" operator="erode" in="SourceAlpha" result="shadowInner"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowInner" result="shadowInner"></feOffset>
|
||||
<feComposite in="shadowOffsetOuter1" in2="shadowInner" operator="out" result="shadowOffsetOuter1"></feComposite>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<path d="M61,890 C61,852.213277 52.8468526,845.02019 43.6409723,842.023611 C31.7052989,838.138466 18,841.307577 18,794" id="path-45"></path>
|
||||
<filter x="-7.0%" y="-3.1%" width="114.0%" height="106.2%" filterUnits="objectBoundingBox" id="filter-46">
|
||||
<feMorphology radius="1.5" operator="dilate" in="SourceAlpha" result="shadowSpreadOuter1"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowSpreadOuter1" result="shadowOffsetOuter1"></feOffset>
|
||||
<feMorphology radius="1.5" operator="erode" in="SourceAlpha" result="shadowInner"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowInner" result="shadowInner"></feOffset>
|
||||
<feComposite in="shadowOffsetOuter1" in2="shadowInner" operator="out" result="shadowOffsetOuter1"></feComposite>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<circle id="path-47" cx="17" cy="17" r="17"></circle>
|
||||
<filter x="-3.8%" y="-3.8%" width="107.6%" height="107.6%" filterUnits="objectBoundingBox" id="filter-48">
|
||||
<feGaussianBlur stdDeviation="0.1" in="SourceGraphic"></feGaussianBlur>
|
||||
</filter>
|
||||
<filter x="-5.3%" y="-5.3%" width="110.6%" height="110.6%" filterUnits="objectBoundingBox" id="filter-49">
|
||||
<feOffset dx="0" dy="0" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feComposite in="shadowBlurOuter1" in2="SourceAlpha" operator="out" result="shadowBlurOuter1"></feComposite>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<path d="M61,708 C61,670.213277 52.8468526,663.02019 43.6409723,660.023611 C31.7052989,656.138466 18,659.307577 18,612" id="path-50"></path>
|
||||
<filter x="-7.0%" y="-3.1%" width="114.0%" height="106.2%" filterUnits="objectBoundingBox" id="filter-51">
|
||||
<feMorphology radius="1.5" operator="dilate" in="SourceAlpha" result="shadowSpreadOuter1"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowSpreadOuter1" result="shadowOffsetOuter1"></feOffset>
|
||||
<feMorphology radius="1.5" operator="erode" in="SourceAlpha" result="shadowInner"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowInner" result="shadowInner"></feOffset>
|
||||
<feComposite in="shadowOffsetOuter1" in2="shadowInner" operator="out" result="shadowOffsetOuter1"></feComposite>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<path d="M156,877 C156,849.543599 135.468474,839.505513 123.531023,839.505513 C89.1020155,839.505513 21.3356341,844.650003 18,792" id="path-52"></path>
|
||||
<filter x="-2.2%" y="-3.5%" width="104.3%" height="107.1%" filterUnits="objectBoundingBox" id="filter-53">
|
||||
<feMorphology radius="1.5" operator="dilate" in="SourceAlpha" result="shadowSpreadOuter1"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowSpreadOuter1" result="shadowOffsetOuter1"></feOffset>
|
||||
<feMorphology radius="1.5" operator="erode" in="SourceAlpha" result="shadowInner"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowInner" result="shadowInner"></feOffset>
|
||||
<feComposite in="shadowOffsetOuter1" in2="shadowInner" operator="out" result="shadowOffsetOuter1"></feComposite>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
<path d="M155,610 C154.999469,599.834463 149.681444,566.661279 110.774387,566.661279 C64.3242005,566.661279 64.3242005,559.30254 61,507" id="path-54"></path>
|
||||
<filter x="-3.2%" y="-2.9%" width="106.4%" height="105.8%" filterUnits="objectBoundingBox" id="filter-55">
|
||||
<feMorphology radius="1.5" operator="dilate" in="SourceAlpha" result="shadowSpreadOuter1"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowSpreadOuter1" result="shadowOffsetOuter1"></feOffset>
|
||||
<feMorphology radius="1.5" operator="erode" in="SourceAlpha" result="shadowInner"></feMorphology>
|
||||
<feOffset dx="0" dy="0" in="shadowInner" result="shadowInner"></feOffset>
|
||||
<feComposite in="shadowOffsetOuter1" in2="shadowInner" operator="out" result="shadowOffsetOuter1"></feComposite>
|
||||
<feGaussianBlur stdDeviation="0.5" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
|
||||
<feColorMatrix values="0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
|
||||
</filter>
|
||||
</defs>
|
||||
<g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
|
||||
<g id="Green" transform="translate(0.000000, -2546.000000)">
|
||||
<g id="Website-Copy" transform="translate(-31.000000, 0.000000)">
|
||||
<g id="Main" transform="translate(0.000000, 670.000000)">
|
||||
<g id="Break-image" transform="translate(0.000000, 1777.000000)">
|
||||
<g id="Flow" transform="translate(591.000000, 231.500000) rotate(-90.000000) translate(-591.000000, -231.500000) translate(459.500000, -359.500000)">
|
||||
<polyline id="Path-2" stroke="url(#linearGradient-1)" stroke-width="3" points="18 1182 18 163.533194 18 0"></polyline>
|
||||
<polygon id="Path-2" stroke="url(#linearGradient-2)" stroke-width="3" points="244 1173 244 162.288018 244 0"></polygon>
|
||||
<g id="commit" transform="translate(46.000000, 777.000000)">
|
||||
<g id="Oval" filter="url(#filter-4)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-5)" xlink:href="#path-3"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-3"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(138.000000, 777.000000)">
|
||||
<g id="Oval" filter="url(#filter-7)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-8)" xlink:href="#path-6"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-6"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(138.000000, 711.000000)">
|
||||
<g id="Oval" filter="url(#filter-10)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-11)" xlink:href="#path-9"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-9"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(229.000000, 694.000000)">
|
||||
<g id="Oval" filter="url(#filter-13)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-14)" xlink:href="#path-12"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-12"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(229.000000, 629.000000)">
|
||||
<g id="Oval" filter="url(#filter-16)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-17)" xlink:href="#path-15"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-15"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(229.000000, 575.000000)">
|
||||
<g id="Oval" filter="url(#filter-19)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-20)" xlink:href="#path-18"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-18"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(138.000000, 629.000000)">
|
||||
<g id="Oval" filter="url(#filter-22)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-23)" xlink:href="#path-21"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-21"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(138.000000, 500.000000)">
|
||||
<g id="Oval" filter="url(#filter-25)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-26)" xlink:href="#path-24"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-24"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(89.000000, 419.000000)">
|
||||
<g id="Oval" filter="url(#filter-28)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-29)" xlink:href="#path-27"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-27"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(0.000000, 355.000000)">
|
||||
<g id="Oval" filter="url(#filter-31)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-32)" xlink:href="#path-30"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-30"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(89.000000, 355.000000)">
|
||||
<g id="Oval" filter="url(#filter-34)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-35)" xlink:href="#path-33"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-33"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="commit" transform="translate(229.000000, 777.000000)">
|
||||
<g id="Oval" filter="url(#filter-37)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-38)" xlink:href="#path-36"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-36"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="Path-3">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-40)" xlink:href="#path-39"></use>
|
||||
<use stroke="#FFFFFF" stroke-width="3" xlink:href="#path-39"></use>
|
||||
</g>
|
||||
<g id="Path-6">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-42)" xlink:href="#path-41"></use>
|
||||
<use stroke="#FFFFFF" stroke-width="3" xlink:href="#path-41"></use>
|
||||
</g>
|
||||
<g id="Path-7">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-44)" xlink:href="#path-43"></use>
|
||||
<use stroke="#FFFFFF" stroke-width="3" xlink:href="#path-43"></use>
|
||||
</g>
|
||||
<g id="Path-7" transform="translate(39.500000, 842.000000) scale(-1, 1) translate(-39.500000, -842.000000) ">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-46)" xlink:href="#path-45"></use>
|
||||
<use stroke="#FFFFFF" stroke-width="3" xlink:href="#path-45"></use>
|
||||
</g>
|
||||
<g id="commit" transform="translate(46.000000, 593.000000)">
|
||||
<g id="Oval" filter="url(#filter-48)">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-49)" xlink:href="#path-47"></use>
|
||||
<use fill="#FFFFFF" fill-rule="evenodd" xlink:href="#path-47"></use>
|
||||
</g>
|
||||
</g>
|
||||
<g id="Path-7" transform="translate(39.500000, 660.000000) scale(-1, 1) translate(-39.500000, -660.000000) ">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-51)" xlink:href="#path-50"></use>
|
||||
<use stroke="#FFFFFF" stroke-width="3" xlink:href="#path-50"></use>
|
||||
</g>
|
||||
<g id="Path-7" transform="translate(87.000000, 834.500000) scale(-1, 1) translate(-87.000000, -834.500000) ">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-53)" xlink:href="#path-52"></use>
|
||||
<use stroke="#FFFFFF" stroke-width="3" xlink:href="#path-52"></use>
|
||||
</g>
|
||||
<g id="Path-7" transform="translate(108.000000, 558.500000) scale(-1, 1) translate(-108.000000, -558.500000) ">
|
||||
<use fill="black" fill-opacity="1" filter="url(#filter-55)" xlink:href="#path-54"></use>
|
||||
<use stroke="#FFFFFF" stroke-width="3" xlink:href="#path-54"></use>
|
||||
</g>
|
||||
<path d="M154,795 L243,795" id="Path-4" stroke="#FFFFFF" stroke-width="3"></path>
|
||||
<path d="M245,655 L245,798" id="Path-4" stroke="#FFFFFF" stroke-width="3"></path>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 29 KiB |
1
themes/conventional-commits/static/js/bundle.js
Normal file
1
themes/conventional-commits/static/js/bundle.js
Normal file
File diff suppressed because one or more lines are too long
37
themes/conventional-commits/static/js/index.js
Normal file
37
themes/conventional-commits/static/js/index.js
Normal file
@ -0,0 +1,37 @@
|
||||
import AnchorJS from 'anchor-js';
|
||||
|
||||
class App {
|
||||
constructor(anchors) {
|
||||
this.anchors = anchors;
|
||||
this.onInit();
|
||||
}
|
||||
|
||||
_addEventListeners() {
|
||||
// using 'load' instead of 'DOMContentLoaded' because we want to wait the css
|
||||
// https://javascript.info/onload-ondomcontentloaded
|
||||
window.addEventListener('load', () => {
|
||||
// wrapped in a timeout for wait css parsing
|
||||
setTimeout(() => this._onPageLoaded(), 0);
|
||||
});
|
||||
}
|
||||
|
||||
_onPageLoaded() {
|
||||
this.removeLoadingClass();
|
||||
}
|
||||
|
||||
onInit() {
|
||||
this.addAnchorsLinks();
|
||||
this._addEventListeners();
|
||||
}
|
||||
|
||||
addAnchorsLinks() {
|
||||
this.anchors.options = {placement: 'left'};
|
||||
this.anchors.add();
|
||||
}
|
||||
|
||||
removeLoadingClass() {
|
||||
document.body.classList.remove('conventional-commits--loading');
|
||||
}
|
||||
}
|
||||
|
||||
const app = new App(new AnchorJS());
|
||||
7
themes/conventional-commits/theme.toml
Normal file
7
themes/conventional-commits/theme.toml
Normal file
@ -0,0 +1,7 @@
|
||||
name = "Conventional Commits"
|
||||
license = "MIT"
|
||||
description = "Hugo theme for Conventional Commits website"
|
||||
homepage = "https://github.com/lorenzodianni/hugo-conventional-commits-theme"
|
||||
tags = []
|
||||
features = []
|
||||
min_version = "0.42"
|
||||
Loading…
Reference in New Issue
Block a user