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:
- 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)
- 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
- Run the
git fetch upstream master
command to fetch all branches. - Set up the local
master
branch to track the remotemaster
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
Commit changes. Always provide clear commit messages to track commit changes easier.
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.