CONTRIBUTING.md: update the github workflow (#12000)

This commit is contained in:
Zhang Jian
2019-09-03 14:38:35 +08:00
committed by pingcap-github-bot
parent d9e7bd315e
commit 7267ca30eb

View File

@ -100,188 +100,7 @@ TiDB uses [`Go Modules`](https://github.com/golang/go/wiki/Modules) to manage de
## Workflow
### Step 1: Fork in the cloud
1. Visit https://github.com/pingcap/tidb
2. Click `Fork` button (top right) to establish a cloud-based fork.
### Step 2: Clone fork to local storage
Per Go's [workspace instructions][go-workspace], place TiDB's code on your
`GOPATH` using the following cloning procedure.
Define a local working directory:
```sh
# If your GOPATH has multiple paths, pick
# just one and use it instead of $GOPATH here.
working_dir=$GOPATH/src/github.com/pingcap
```
> If you already worked with Go development on github before, the `pingcap` directory
> will be a sibling to your existing `github.com` directory.
Set `user` to match your github profile name:
```sh
user={your github profile name}
```
Create your clone:
```sh
mkdir -p $working_dir
cd $working_dir
git clone https://github.com/$user/tidb.git
# the following is recommended
# or: git clone git@github.com:$user/tidb.git
cd $working_dir/tidb
git remote add upstream https://github.com/pingcap/tidb.git
# or: git remote add upstream git@github.com:pingcap/tidb.git
# Never push to upstream master since you do not have write access.
git remote set-url --push upstream no_push
# Confirm that your remotes make sense:
# It should look like:
# origin git@github.com:$(user)/tidb.git (fetch)
# origin git@github.com:$(user)/tidb.git (push)
# upstream https://github.com/pingcap/tidb (fetch)
# upstream no_push (push)
git remote -v
```
#### Define a pre-commit hook
Please link the TiDB pre-commit hook into your `.git` directory.
This hook checks your commits for formatting, building, doc generation, etc.
```sh
cd $working_dir/tidb/.git/hooks
ln -s ../../hooks/pre-commit .
```
Sometime, pre-commit hook can not be executable. In such case, you have to make it executable manually.
```sh
cd $working_dir/tidb/.git/hooks
chmod +x pre-commit
```
### Step 3: Branch
Get your local master up to date:
```sh
cd $working_dir/tidb
git fetch upstream
git checkout master
git rebase upstream/master
```
Branch from master:
```sh
git checkout -b myfeature
```
### Step 4: Develop
#### Edit the code
You can now edit the code on the `myfeature` branch.
#### Run stand-alone mode
If you want to reproduce and investigate an issue, you may need
to run TiDB in stand-alone mode.
```sh
# Build the binary.
make server
# Run in stand-alone mode. The data is stored in `/tmp/tidb`.
bin/tidb-server
```
Then you can connect to TiDB with mysql client.
```sh
mysql -h127.0.0.1 -P4000 -uroot test
```
If you use MySQL client 8, you may get the `ERROR 1105 (HY000): Unknown charset id 255` error. To solve it, you can add `--default-character-set utf8` in MySQL client 8's arguments.
```sh
mysql -h127.0.0.1 -P4000 -uroot test --default-character-set utf8
```
#### Run Test
Run all tests
```sh
# Run unit test to make sure all test passed.
make dev
# Check checklist before you move on.
make checklist
```
You can also run a single test in a file. For example, if you want to run
test `TestToInt64` in file `types/datum.go`, you can do something like
```sh
cd types
GO111MODULE=on go test -check.f TestToInt64
```
### Step 5: Keep your branch in sync
```sh
# While on your myfeature branch.
git fetch upstream
git rebase upstream/master
```
### Step 6: Commit
Commit your changes.
```sh
git commit
```
Likely you'll go back and edit/build/test some more than `commit --amend`
in a few cycles.
### Step 7: Push
When ready to review (or just to establish an offsite backup or your work),
push your branch to your fork on `github.com`:
```sh
git push -f origin myfeature
```
### Step 8: Create a pull request
1. Visit your fork at `https://github.com/$user/tidb` (replace `$user` obviously).
2. Click the `Compare & pull request` button next to your `myfeature` branch.
### Step 9: Get a code review
Once your pull request has been opened, it will be assigned to at least two
reviewers. Those reviewers will do a thorough code review, looking for
correctness, bugs, opportunities for improvement, documentation and comments,
and style.
Commit changes made in response to review comments to the same branch on your
fork.
Very small PRs are easy to review. Very large PRs are very difficult to
review.
See the [Github Workflow](https://github.com/pingcap/community/blob/master/contributors/workflow.md)
## Code style