PR Settings
Pull Requests (PRs) are an essential tool for collaborative development, and GitCode offers various PR settings options to help you customize the code review and merge process. The following content will guide you through these settings and their functions.
Overview of Basic PR Settings
The basic PR settings and descriptions are as follows:
| Feature | Description |
|---|---|
| Minimum number of reviewers | Set the minimum number of reviewers required to merge a PR to ensure code quality through sufficient reviews. |
| PR can only be merged after all review comments are resolved | Prevent merging a PR until all review comments are marked as resolved. |
| Pipeline must pass | Ensure that the associated pipeline tasks run successfully and pass checks before merging a PR. |
| Enable lightweight Pull Request | Provide a simplified version of PR functionality, suitable for simpler change request scenarios. |
| Prohibit merging your own Pull Request | Prevent developers from merging their own PRs to enhance the objectivity of code reviews. |
| Allow administrators to force merge | Grant administrators the permission to bypass restrictions and force merge PRs. |
| Automatically select "Close associated Issues after merge" when creating a Pull Request | Improve efficiency by automatically marking resolved issues as closed. |
| Allow reopening a PR after it is closed | Allow developers to reopen a PR that has been closed, suitable for scenarios involving requirement changes or mistakes. |
| Allow code review and comments after PR merge | Retain the function of code review and comments after PR merge for subsequent discussions. |
| Mark auto-merged PRs as closed | Add a closed status marker to auto-merged PRs for easier distinction and management. |
| Automatically delete source branch after PR merge | Increase branch management efficiency and reduce the occupation of unnecessary branches in the repository. |
| Disable Squash merge (prohibit Squash merge when merging PR) | Disable Squash merge to preserve the complete commit history. |
| New Pull Request defaults to enabling Squash merge | Default to enable Squash merge, compressing multiple commits into a single one to optimize the history record. |
| Merge mode | Provide three merge mode options: merge via merge commit, merge via merge commit (record half-linear history), and Fast-forward merge. |
Merge Mode
GitCode supports the following three merge modes, and you can choose the appropriate method based on your needs:
| Merge Mode | Description | Features | Options |
|---|---|---|---|
| Merge via merge commit | A merge commit submission is generated for each merge operation to record the merge history. | 1. Even if the commits in the PR are not based on the latest commit point of the target branch, the merge can still be performed directly. 2. Squash merge does not generate a Merge node. | 1. Use the merge commit created by the PR merger. 2. Use the merge commit created by the PR creator. |
| Merge via merge commit (record half-linear history) | A merge commit submission is generated for each merge operation but requires meeting the Fast-forward condition, i.e., all commits in the PR need to be based on the latest commit point of the target branch. | 1. If the condition is not met, developers need to perform a rebase operation. 2. This mode ensures that the target branch can be correctly built after the merge. | None |
| Fast-forward merge | No merge commit submission is generated during the merge operation; it is only executed under the Fast-forward condition. | 1. The commits in the PR need to be based on the latest commit point of the target branch. 2. If the condition is not met, developers need to perform a rebase operation. | None |
PR Review Settings
Allow automatic assignment of reviewers and testers when creating a Pull Request to simplify team members' workflows and improve the efficiency of code review and merge processes.
Code Review Settings
- The system will automatically assign predefined reviewers when creating a PR to ensure timely code review.
- You can set the minimum number of people required to pass the review to ensure that the code changes meet the team's quality requirements.
Code Testing Settings
- The system will automatically assign testers when creating a PR to be responsible for executing the testing work for the code changes.
- Set the minimum number of people required to pass the test to ensure that changes are sufficiently validated and potential issues are reduced.
By reasonably configuring the review and testing settings, teams can effectively divide tasks in the code merge process, reduce communication costs, increase development efficiency, and ensure code quality.