Skip to main content

Basic rules

ByConity is leverage the Github doing the developement. Each contributor and maintainer in ByConity must follow this workflow:

  • Work on forked repositories.
  • Create branches on the fork repo and avoid working directly on the master branch.

Prepare the fork​

A fork is a copy of the repository from which you raise pull requests to propose changes to the original repository.

Configure your fork​

The document refers to the original repository as the upstream repository and to the forked repository as the origin repository. We assume you already have a fork of the upstream and you git clone it already.

Working on a Fork on local​

Configure a remote repository that points to the upstream repository. This allows you to synchronize changes you make on the fork with the original repository.

In the terminal, navigate to the location of your fork and perform the following steps:

  1. Run the git remote -v command to list the current configured remote repository for your fork. The result is as follows:
    origin  https://github.com/{your-username}/{your-fork}.git (fetch)
    origin  https://github.com/{your-username}/{your-fork}.git (push)

See the example:

    origin  https://github.com/YourName/ByConity.git (fetch)
    origin  https://github.com/YourName/ByConity.git (push)
  1. Specify a new remote upstream repository to synchronize with the fork:
    git remote add upstream https://github.com/{original-owner}/{original-repository}.git

See the example:

    git remote add upstream https://github.com/ByConity/ByConity.git
  1. Run the git fetch upstream master command to fetch all branches.
  2. Set up the local master branch to track the remote master branch from the upstream repository:
    git branch -u upstream/master master

Now, each time you rebase or check out the master branch, you refer to the master branch of the upstream repository. In other words, when you create a branch from local up-to-date master means creating a branch from latest upstream master.

To verify that your local master branch points to the upstream/master, run the git branch -vv command. The result is similar to the following:

* master         6a43546 [upstream/master] Translate Background Tasks Configuration in English

  1. Commit changes. Always provide clear commit messages to track commit changes easier.

  2. Create a pull request from the branch of your forked repository to the master branch of the upstream repository and wait for the maintainers' review.

Pull requests should have a title that follows the specification, otherwise, merging is blocked. If you are not familiar with the specification simply ask maintainers to modify. You can also use this cheatsheet if you want:

  • fix: prefix in the title indicates that PR is a bug fix and PATCH release must be triggered.
  • feat: prefix in the title indicates that PR is a feature and MINOR release must be triggered.
  • docs: prefix in the title indicates that PR is only related to the documentation and there is no need to trigger release.
  • perf: prefix in the title indicates that PR is only related to performance relates changes in the project and there is no need to trigger release.
  • chore: prefix in the title indicates that PR is only related to cleanup in the project and there is no need to trigger release.
  • test: prefix in the title indicates that PR is only related to tests and there is no need to trigger release.
  • refactor: prefix in the title indicates that PR is only related to refactoring and there is no need to trigger release.

Reference