Repositories
To configure repository settings, you can choose
on the repository details page.The default branch is the branch selected by default when you enter the current repository and is also the default target branch when you create a merge request (MR). When a repository is created, the master branch is used as the default branch and can be manually adjusted at any time.
The settings take effect only for the repository configured.
All repository members can view this page. For details about whether a repository member has repository setting permissions, refer to the Permissions page.
Parameter |
Description |
---|---|
Do not fork a repo. |
This parameter is not selected by default. If this parameter is selected, all users cannot fork the repository. |
Whitelist for creating branches |
By default, this parameter is not selected. If it is selected, the developer whitelist for creating branches is enabled.
NOTE:
Only developers (excluding roles changed to non-developer) are allowed to create branches. |
Pre-merge |
By default, this option is not selected. After this option is selected, the server automatically generates MR pre-merging code. Compared with running commands on the client, this operation is more efficient and simple, and the build result is more accurate. This option applies to scenarios that have strict requirements on real-time build. |
- Byte: a group of adjacent binary digits. It is an important data unit of computers and is usually represented by B. 1 B = 8 bits.
- Character: a letter, digit, or another symbol that represents data and information.
Configuring MR Pre-combination
After an MR is created, you can customize the scripts for downloading plug-ins such as webhook and pipeline. That is, you can control the downloaded code content.
- If MR Pre-merge is selected, the server will generate a hidden branch, indicating that the MR code has been merged. You can directly download the code that already exists in the hidden branch.
- If Pre-merge is not selected, you need to perform pre-merge on the client. That is, download the code of the MR source branch and MR target branch and perform pre-merge on the build executor.
Command
The pre-merge command on the server is as follows:
git init git remote add origin ${repo_url clone/download address} git fetch origin +refs/merge-requests/${repo_MR_iid}/merge:refs/${repo_MR_iid}merge
If this option is not selected, you can perform the pre-merge operation on the client and create a clean working directory on the local host. The command is as follows:
git init git remote add origin ${repo_url clone/download address} git fetch origin +refs/heads/${repoTargetBranch}:refs/remotes/origin/${repoTargetBranch} git checkout ${repoTargetBranch} git fetch origin +refs/merge-requests/${repo_MR_iid}/head:refs/remotes/origin/${repo_MR_iid}/head git merge refs/remotes/origin/${repo_MR_iid}/head --no-edit
Advantages
In scenarios that have high requirements on real-time build, for example, one MR may start the build of dozens or hundreds of servers, and the pre-merging result generated by the local or client may be inconsistent with that generated by the server. As a result, the build code cannot be obtained accurately and the build result is inaccurate. Pre-merging on the server can solve this problem in real time. In addition, the script building command is simpler, and developers or CIEs can better use it.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot