開発

Python

スタイルガイド

docstring

Workflow

Packaging

general

API

NumPy

xarray

scikit-learn

可視化

公開

PyPI

conda-forge

Git/GitHub

Commit message

Conventional Commits 

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

あなたのライブラリの利用者に意図を伝えるために、コミットは以下の構造化された要素を持ちます：

  1. fix: 型 fix を持つコミットはコードベースのバグにパッチを当てます (これは Semantic Versioning における PATCH に相当します)。
  2. feat: 型 feat を持つコミットはコードベースに新しい機能を追加します (これは Semantic Versioning における MINOR に相当します)。
  3. BREAKING CHANGE: フッター に BREAKING CHANGE: が書かれているか型/スコープの直後に ! が追加されているコミットは API > の破壊的変更を導入します (Semantic Versioning における MAJOR に相当します)。 BREAKING CHANGE は任意の 型 > のコミットに含めることができます。
  4. fix: や feat: 以外の 型 も許されています。たとえば @commitlint/config-conventional (これは Angular の規約 > が基になっています) は build:, chore:, ci:,docs:, style:, refactor:, perf:, test:, などを推奨しています。
  5. git trailer format に似た規約に従って、BREAKING CHANGE: <タイトル> 以外の フッター が与えられるかもしれません。

追加の型たちは Conventional Commits の仕様で義務付けられているものではなく、(BREAKING CHANGE を含まない限り) Semantic > Versioning に対する暗黙的な効果を持ちません。

コミットの型には追加の文脈の情報として スコープ を追加することができます。スコープは括弧で囲みます。たとえば feat(parser): add > ability to parse arrays のようになります。

Numpy 

# Standard acronyms for commit message prefixes in NumPy dev
API: an (incompatible) API change
BENCH: changes to the benchmark suite
BLD: change related to building numpy
BUG: bug fix
DEP: deprecate something, or remove a deprecated object
DEV: development tool or utility
DOC: documentation
ENH: enhancement
MAINT: maintenance commit (refactoring, typos, etc.)
REV: revert an earlier commit
STY: style fix (whitespace, PEP8)
TST: addition or modification of tests
REL: related to releasing numpy

Emoji-Log 

📦 NEW: IMPERATIVE_MESSAGE_GOES_HERE
	Use when you add something entirely new. E.g. 📦 NEW: Add Git ignore file
👌 IMPROVE: IMPERATIVE_MESSAGE_GOES_HERE
	Use when you improve/enhance piece of code like refactoring etc. E.g. 👌 IMPROVE: Remote IP API Function
🐛 FIX: IMPERATIVE_MESSAGE_GOES_HERE
	Use when you fix a bug — need I say more? E.g. 🐛 FIX: Case conversion
📖 DOC: IMPERATIVE_MESSAGE_GOES_HERE
	Use when you add documentation like README.md, or even inline docs. E.g. 📖 DOC: API Interface Tutorial
🚀 RELEASE: IMPERATIVE_MESSAGE_GOES_HERE
	Use when you release a new version. E.g. 🚀 RELEASE: Version 2.0.0
🤖 TEST: IMPERATIVE_MESSAGE_GOES_HERE
	Use when it's related to testing. E.g. 🤖 TEST: Mock User Login/Logout
‼️ BREAKING: IMPERATIVE_MESSAGE_GOES_HERE
	Use when releasing a change that breaks previous versions. E.g. ‼️ BREAKING: Change authentication protocol

Jupyter Book 

‼️ BREAKING: (:bangbang:) — to introduce a back-incompatible change(s) (and/or remove deprecated code).
✨ NEW: (:sparkles:) — to introduce a new feature(s).
👌 IMPROVE: (:ok_hand:) — to improve an existing code/feature (with no breaking changes).
🐛 FIX: (:bug:) — to fix a code bug.
📚 DOCS: (:books:) — to add new documentation.
🔧 MAINTAIN: (:wrench:) — to make minor changes (like fixing typos) which should not appear in a changelog.
🧪 TEST: (:test_tube:) — to add additional testing only.
🚀 RELEASE: (:rocket:) — to bump the package version for release.
⬆️ UPGRADE: (:arrow_up:) — for upgrading a dependency pinning.
♻️ REFACTOR: (:recycle:) — for refactoring existing code (with no specific improvements).
🗑️ DEPRECATE: (:wastebasket:) — mark some code as deprecated (for removal in a later release). The future version when it will be removed should also be specified, and (if applicable) what will replace it.
🔀 MERGE: (:twisted_rightwards_arrows:) — for a merge commit (then all commits within the merge should be categorised)
❓ OTHER: (:question:) — anything not covered above (use as a last resort!).

Release

Mathematica

Paclet

命名

ライセンス