Home

Welcome to the Biblio App wiki!

Conventional commits

Format: <type>(<scope>): <subject>

<scope> is optional

Example

feat: added a nice feature
^--^  ^------------------^
|     |
|     +-> Summary in past tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

More Examples

docs: explaining how to code
feat: added beta sequence
fix: remove bug beta sequence
refactor: a change in existing code
style: convert tabs to spaces
test: added unit test

Types of Commits

• feat: (used when a commit adds a new feature to your application or library)
• fix: (used when a commit represents a bug fix for your application)
• docs: (changes to the documentation)
• style: (formatting, missing semi colons, etc; no production code change)
• refactor: (refactoring production code, eg. renaming a variable)
• test: (adding missing tests, refactoring tests; no production code change)
• chore: (updating grunt tasks etc; no production code change)
• cleanup: (removing unused files, folders or code)

Branch Rules

Format

Branch rules in this repository follow a specific format to ensure consistency and clarity in the development process. The naming convention for branches is crucial for easy identification of their purpose. Use prefixes such as "feature/" or "bugfix/" to provide a clear context for each branch.

Example

feature/add-new-feature
^-------^ ^------------^
|         |
|         +-> Concise and descriptive summary.
|
+----------> Prefix: feature/, indicating the type of branch.

Protection Rules

To maintain code quality and prevent accidental errors, protection rules are applied to main branches. These rules enforce a pull request workflow, requiring code reviews before merging changes into the main codebase. An example configuration may include requiring approval from at least two team members, ensuring all tests pass, and prohibiting direct pushes to protected branches.

Branch Protection Rule

- Require at least 2 approving reviews for pull requests.
- Disallow direct pushes to main branches.
- Require passing status checks before merging.

Naming rules

Functions

• Use descriptive names
• Choose names that clearly convey the purpose of the function.
• Use camelCase
• Avoid generic names like foo() or bar().

function calculateTotal() {...}
function getUserData() {..}

Files

• Use meaningful names
• Avoid generic names like temp.txt or newfile.js.
• Use lowercase
• use kebab-case