This guide describes some development conventions we adopt at Bytebase.

This section describes how to manage git branches.

Since git utilizes branches as a primary development pattern, we usually face the problem of branch management. We suggest naming your fork of the code, i.e. ${YourGithubID}/bytebase as origin, and the repo bytebase/bytebase as upstream. Here's a guide for following this branch development pattern.

After forking the bytebase/bytebase repository, set up the git remote tracking.

# clone your Bytebase fork
git clone git@github.com:${YourGithubID}/bytebase.git
cd bytebase
# setup upstream pointing to bytebase/bytebase
git remote add upstream git@github.com:bytebase/bytebase.git
# check the result
git remote -v
# expected outputs:
#   origin     git@github.com:${YourGithubID}/bytebase.git (fetch)
#   origin     git@github.com:${YourGithubID}/bytebase.git (push)
#   upstream   git@github.com:bytebase/bytebase.git (fetch)
#   upstream   git@github.com:bytebase/bytebase.git (push)

Now you have set up two tracked repositories: upstream for bytebase/bytebase and origin for your fork.

We usually create a new branch when we start developing a new feature. Here's a typical workflow.

# checkout to the main branch
git checkout main
# sync with the upstream
git pull upstream main
# create and checkout to your new feature branch
git checkout -b feat/xxx
# coding & commit
# push to origin
git push
# then git will prompt you with a complete command to push and track to the origin, copy & paste
git push --set-upstream origin feat/xxx

The recommended branch naming convention is using / as a namespace separator, e.g., feat/xxx, chore/xxx, docs/xxx, which works nicely with 3rd party git tools such as GitLens.

This section describes how we add human and machine-readable commit messages.

Refer to Conventional Commits 1.0.0

• Automatically generating CHANGELOGs and release notes.
• Communicating the nature of changes to teammates, the public, and other stakeholders.
• Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.

Conventional Commits specification is a lightweight convention on top of commit message. It provides an easy set of rules for creating an explicit commit history, which improves better readability, velocity and automation.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The header is a mandatory line that simply describes the purpose of the change.

<type>[optional scope]: <description>

It consists of three parts in itself:

• Type - a short prefix that represents the kind of the change
• Scope - optional information that represents the context of the change
• Subject - represents a concise description of actual change

💡 Notice that there also has a colon and space(:<space>), which separated the type and description

The body is optional lines that introduce the motivation behind the change or just describing slightly more detailed information.

The footer is optional lines that mention consequences which stems from the change - such as announcing a breaking change, linking closed issues, mentioning contributors and so on.

docs: correct spelling of CHANGELOG

feat(lang): add polish language

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Reviewed-by: Z

On top of defining the commit message format, the Angular commit message conventions specify a list of useful types that cover various sorts of changes.

Used for add some feature

feat: add some feature
feat(frontend): add some feature in frontend

Used for fixed some bug

fix: fixed typo
fix(frontend): fixed some error in frontend scope

Used for write some docs

docs: add a new docs

Used for refactor some old code or maybe rewrite、enchance it

refactor: rewrite some logic

Generally used for front-end

style: update the ui colors

Used for add some test case

test: test some case

Used for some performance improvements.

perf: reduce the api requests when page loading

Used for changes the build process, bump up version, add some configs etc.

chore: release v0.0.1
chore: bump up dependencies version

Checkout more examples

• commitizen - The commitizen command line utility.
• cz-conventional-changelog - A commitizen adapter for the angular preset of conventional-changelog
• husky - Git hooks made easy 🐶 woof!
• conventional-changelog-cli - Generate changelogs and release notes from a project's commit messages and metadata.