同步操作将从 OpenHarmony/docs 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
Perform the following steps to download the code in the repository to your computer:
Create a local working directory.
A local working directory is used for searching and managing local code.
mkdir ${your_working_dir}
Clone the remote repository to the local host.
Switch to the local path.
mkdir -p ${your_working_dir}
cd ${your_working_dir}
Clone the remote repository.
You can copy the address of the remote repository on the repository page.
Figure 1 Cloning the remote repository
Run the following command on the local host:
git clone $remote_link
Download the repo tool. (For details, see https://gitee.com/help/articles/4316.)
curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo
chmod a+x /usr/local/bin/repo
pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests
Download code repositories. (There is no repo branch parameter.)
repo init -u https://gitee.com/openharmony/manifest.git -b master
repo sync -c
Update the branch.
Update your local branch.
git remote add origin $remote_link
git fetch origin
git checkout master
git pull --rebase
Update the local debugging branch (myfeature branch) based on the remote master branch.
git branch myfeature origin/master
git checkout myfeature
Then, edit and modify the code in the myfeature branch.
Commit the changes in the local working directory.
git add .
git commit -sm "xxxxxx" // Commit changes with a message containing the signoff email address.
You may continue to edit and test more content after the previous commit. You can use commit --amend to commit these changes.
Push the changes to your remote directory.
If you plan to review (or just establish a remote backup of your work), push the branch to your fork repository:
git push -f origin myfeature
repo config --global repo.token {TOKEN}
The token is generated by choosing Settings > Security Settings > Private Token on Gitee. Example:
repo config --global repo.token 211XXXXXXXXXXXXXXXXXXXXXXXX
Create an issue under any repository to be modified on Gitee, and record the issue number (for example, #I1TVV4 in the following figure). (The issue provides a function similar to change ID of Gerrit and is used to associate multiple repositories to be modified. Skip this step if modification of multiple repositories is not involved.)
Create a branch in the local code workspace, modify the code, and commit the changes.
repo start branchname --all
After the code is modified, run the following command in multiple repositories:
git add .
git commit -sm "xxxxxx"
Alternatively, use the repo tool to batch add or commit the changes in the root directory of the code project:
repo forall -c 'git add .'
repo forall -c 'git commit -sm "xxxxxx"'
Specify whether to directly generate a pull request (PR) during code push. The value False indicates that a PR is not directly generated and needs to be manually generated in the fork warehouse. The value True indicates that a PR is generated when the code is pushed to the fork repository.
repo config repo.pullrequest {True/False}
For example, if the PR is generated when the push code is selected, run the following command:
repo config repo.pullrequest True
Run the following command to push the code:
repo push --br={BRANCH} --d={DEST_BRANCH} --content={PR_CONTENT}
BRANCH indicates the local branch, DEST_BRANCH indicates the destination branch (trunk branch), which is usually master, and PR_CONTENT indicates the PR description. If multi-repository committing is involved, the issue number must be entered. Example:
repo push --br="20200903" --d="master" --content="#I1TVV4"
On the editing page displayed, open the comment tags for the repository, branch, and commit.
Save the settings and exit. The repo tool automatically pushes the local branch to the remote fork repository (creates a fork repository if there is no fork repository) and generates a PR.
The tool automatically associates the PR with the issue.
Access the fork repository on Gitee, click the button for creating a PR, and select the myfeature branch to generate a PR. (Skip this step if a PR has been automatically created using the repo tool.)
For details, visit https://gitee.com/help/articles/4128.
NOTICE
How do I create PRs at the same time if multiple code repositories have compilation dependencies? During the development of the operating system (OS), it is common that multiple code repositories have compilation dependencies. Therefore, the PRs need to be created and merged at the same time. For this reason, Gitee uses issues as the dependency identifiers for code repositories with compilation dependencies to commit the PRs. Follow the operations below:
- Create an issue in any of the code repositories.
- Associate PRs that need to be built and merged at the same time with the issue. For details, visit https://gitee.com/help/articles/4142.
- After the build is triggered, the build center identifies the PRs associated with the same issue, downloads the build, and merges the PRs into the code library after the code is approved.
When creating a PR or compiling an existing PR, enter #+I+five-digit issue ID in the description box to associate the issue with the PR.
Constraints
Comment "start build" in the PR to trigger CI access control.
If multiple PRs are associated with the same issue, the comment "start build" on any PR can trigger the CI access control of the issue.
After the access control is executed, the execution result will be automatically commented in all the PRs associated with the issue.
If the access control is passed, all PRs associated with the issue will be automatically marked as "Passed".
The continuous integration (CI) portal is a platform where you can promptly view and analyze the execution results of code access control and daily build.
On the CI portal, you can detect code bugs in a timely manner to ensure code reliability and function stability. The CI portal provides the following functions:
Code Access Control: After submitting a merge request to commit code, code access checks, such as the static code check, code build, and function test, are triggered. Code can be committed only after all checks are passed.
Daily Build: The continuous integration pipeline is automatically executed every day to detect issues with static code, code build, and functions in advance, thereby allowing you to resolve these issues in time to ensure high code quality.
Visit CI portal.
For details, visit https://gitee.com/help/articles/4304.
Related topic: FAQs
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。