Thank you for your contribution to TuGraph. We sincerely hope that more students from the community will join in and build a better graph database project together.
For outstanding community contributors, we will award the TuGraph Outstanding Community Contributor Certificate.
We welcome any contribution at any time, whether it's a simple typo fix, bug fix, or new feature addition. Feel free to ask questions or initiate PRs. We also value documentation and integration with other open source projects, and welcome contributions in this regard. For any modification, especially the more complex modification, it is recommended to create an issue and fill it out according to the BUG or PR template.
You can get start with TuGraph follow instrcutions in Guide Doc.
For document contributions, you can directly modify and submit a pull request by clicking on "Edit on GitHub" in the upper right corner of the documentation.
For code contributions, it is usually necessary to set up the environment for compilation and execution. You can deploy using Docker or local package deployment.
Before contributing code, please take some time to understand the process of contributing code to TuGraph, and read the Contributor License Agreement or Corporate Contributor License Agreement. Participating in the contribution is deemed to agree to the above agreement.
Whether you are fixing a bug in TuGraph or adding a new feature to TuGraph, before you submit the code, submit an issue on TuGraph's GitHub, describing the problem you want to fix or the function you want to add. There are several advantages to doing this:
- There will be no duplication of work in conflict with other developers or their plans for the project.
- TuGraph maintainers will discuss the bugs or new features you mentioned to determine whether the modification is necessary, whether there is room for improvement or a better way.
- After reaching an agreement, develop and submit the code, reducing the cost of communication between the two parties and reducing the rejection of pull requests.
All modifications of TuGraph are made on branches. After modification, the pull request is submitted and merged into the Master by the project maintenance personnel after Code Review. Therefore, after the source code steps are described, you need:
- Download the code to a local directory. In this step, you can choose git or https. In recent years, github has stricter permission requirements. The git approach, for example, requires the more complex ssh key(https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent). https authentication cannot be performed using the user name and password. git clone https://github.com/ Your account name /tugraph-db
- Pull branch ready to modify code: git branch add_xxx_feature
- After executing the above command, your code repository switches to the appropriate branch. Run the following command to view your current branch: git branch -a
- If you want to switch back to Master, run the git checkout -b master command
- If you want to switch back to branching, run the following command: git checkout -b "branchName"
Run git config --list on your machine to view git's global username and mailbox. Check whether the displayed user.name and user.email match your github user name and email address.
If a company has its own gitlab in-house or uses other commercial GitLabs, a mismatch may occur. At this point, you need to set up a separate user name and mailbox for the tugraph-db project. For details about how to set the user name and email address, see github's official documentation.
The process of compile and run can reference ci script
Once you've pulled the branch, you're ready to change the code.
Code modification Notes
Code style consistency: TuGraph uses cpplint to keep code in the same format, and IDE can use.clang to configure the style. Be sure to check the code style locally before submitting it, or ACI will report an error.
Add unit test code: New changes should pass through existing unit tests. New unit tests should be provided to prove that there are bugs in the previous code and that the new code has resolved these bugs. You can run all tests with the following command:./unit_test It can also be run with the help of an IDE.
Other precautions
Please keep the code you are editing in the original style, especially the space feed, etc. For unnecessary comments, delete them directly. Add comments where logic and functionality are not easily understood. Keep documentation up to date. After modifying the code, run the following command to submit all the changes to the local computer: git commit -am '(feat) Add the xx function 'git commit -am '(fix) fix xx problem' '
Submit the code to the remote repository After the code is committed locally, you can then synchronize the code with the remote repository. Run the following command to submit local changes to github: git push origin "branchname"
If you were forking earlier, the origin here is pushed to your code repository, not TuGraph's.
After the code has been submitted to GitHub, you can send a request to merge your changes into the TuGraph Master. At this point, you need to go to your corresponding repository on GitHub and press the pull request button in the upper right corner. Select the target branch, which is usually the master, and the system will notify the TuGraph staff, who will Review your code, and when it meets the requirements, it will join the main branch and become part of TuGraph.
Please note that the CI will be automatically checked, as well as all Commits signing the cla, with green signs on the commits.
After you submit your code, your code will be assigned to a maintainer for Review. Please wait patiently. If no one has responded to your submission after two working days, you can leave a message under PR and @ the corresponding person.
Comments on code Review will be directly noted to the corresponding PR or Issue. If you find the suggestions reasonable, please update them to your code.
After the code Review is approved, the TuGraph maintainer will put it into the Master. During this process, the maintainer may specify a new Reviewer and put forward new comments that need to be revised. Normally this step is omitted, and after the code is merged, you will receive an indication that the merge was successful.