This guide will explain in detail how to contribute code to the OpenIM project, using `openimsdk/open-im-server` as an example. We adopt a "one issue, one branch" strategy to ensure each issue corresponds to a dedicated branch, allowing for effective management of code changes.
This guide will use [openimsdk/open-im-server](https://github.com/openimsdk/open-im-server) as an example to explain in detail how to contribute code to the OpenIM project. We adopt a "one issue, one branch" strategy to ensure each issue corresponds to a dedicated branch for effective code change management.
### 1. Fork the Repository
### 1. Fork the Repository
Go to the `openimsdk/open-im-server` GitHub page, click the "Fork" button in the upper right corner to fork the repository to your GitHub account.
Go to the [openimsdk/open-im-server](https://github.com/openimsdk/open-im-server) GitHub page, click the "Fork" button in the upper right corner to fork the repository to your GitHub account.
### 2. Clone the Repository
### 2. Clone the Repository
Clone the forked repository to your local machine:
Clone the repository you forked to your local machine:
Create a new issue in the original repository describing the problem you are facing or the new feature you want to add. For significant feature adjustments, propose an RFC issue to facilitate broad discussion and participation from community members.
Create a new issue in the original repository detailing the problem you encountered or the new feature you wish to add.
### 5. Create a New Branch
### 5. Create a New Branch
Create a new branch based on the main branch and name it descriptively, including the Issue ID, for example:
Create a new branch off the main branch with a descriptive name and Issue ID, for example:
```bash
```bash
git checkout -b fix-bug-123
git checkout -b fix-bug-123
```
```
### 6. Commit Changes
### 6. Commit Changes
After making changes on your local branch, commit them:
After making changes on your local branch, commit these changes:
```bash
```bash
git add .
git add .
git commit -m "Describe your changes in detail"
git commit -m "Describe your changes
in detail"
```
```
### 7. Push the Branch
### 7. Push the Branch
@ -67,15 +70,25 @@ git push origin fix-bug-123
```
```
### 8. Create a Pull Request
### 8. Create a Pull Request
Go to your fork on GitHub, click the "Pull Request" button. Make sure the PR description is clear and links to the related Issue.
Go to your fork on GitHub and click the "Pull Request" button. Ensure the PR description is clear and links to the related issue.
#### 🅰 Fixed issue #issueID
### 9. Sign the CLA
### 9. Sign the CLA
If this is your first time submitting a PR, you need to reply in the PR comments:
If this is your first time submitting a PR, you will need to reply in the comments of the PR:
```
```
I have read the CLA Document and I hereby sign the CLA
I have read the CLA Document and I hereby sign the CLA
```
```
### Additional Notes
### Programming Standards
If the same modification needs to be submitted to two different branches (e.g., main and release-v3.7), create two new branches from the corresponding remote branches. First complete the modification in one branch, then use the `cherry-pick` command to apply these changes to the other branch. After that, submit a separate Pull Request for each branch.
Please refer to the following documents for detailed information on Go language programming standards:
- Use the `"github.com/openimsdk/tools/log"` package for logging, which supports multiple log levels: `debug`, `info`, `warn`, `error`.
- **Error logs should only be printed in the function where they are first actively called** to prevent log duplication and ensure clear error context.
### Exception and Error Handling
- **Prohibit the use of `panic`**: The code should not use `panic` to avoid abrupt termination when encountering unrecoverable errors.
- **Error Wrapping**: Use `"github.com/openimsdk/tools/errs"` to wrap errors, maintaining the integrity of error information and facilitating debugging.
- **Error Propagation**: If a function cannot handle an error itself, it should return the error to the caller, rather than hiding or ignoring it.
chao
1 year ago
committed by
GitHub