• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1# Contribution Process<a name="EN-US_TOPIC_0000001052970939"></a>
2
3-   [Preparations](#section124971410183614)
4-   [Downloading Code](#section6125202333611)
5-   [Committing Code](#section338918220422)
6-   [Creating a Pull Request](#section28261522124316)
7-   [Building Access Control](#section981124754415)
8-   [Reviewing Code](#section17823849145014)
9
10## Preparations<a name="section124971410183614"></a>
11
12-   Install, configure, and use Git. For details, visit  [https://gitee.com/help/categories/43](https://gitee.com/help/categories/43).
13-   Register an SSH public key. For details, visit  [https://gitee.com/help/articles/4191](https://gitee.com/help/articles/4191).
14-   Find the repository that you are interested in on the code hosting platform of OpenHarmony.
15
16## Downloading Code<a name="section6125202333611"></a>
17
18## Forking a Code Branch from the Cloud<a name="section8365811818"></a>
19
201.  Find and open the homepage of the repository.
212.  Click the  **Fork**  button in the upper right corner, and create an individual cloud fork branch as prompted.
22
23## Downloading the Fork Repository to the Local Host<a name="section49051646201819"></a>
24
25Perform the following steps to download the code in the repository to your computer:
26
271.  Create a local working directory.
28
29    A local working directory is used for searching and managing local code.
30
31    ```
32    mkdir ${your_working_dir}
33    ```
34
352.  Clone the remote repository to the local host.
36    1.  Switch to the local path.
37
38        ```
39        mkdir -p ${your_working_dir}
40        cd ${your_working_dir}
41        ```
42
43    2.  Clone the remote repository.
44        -   You can copy the address of the remote repository on the repository page.
45
46            **Figure  1** <a name="fig1772512534014"></a>
47
48        -   Run the following command on the local host:
49
50            ```
51            git clone $remote_link
52            ```
53
54
55
56
57## Using the repo Tool to Download Code Repositories in Batches<a name="section15763252468"></a>
58
591.  Download the repo tool. \(For details, see  [https://gitee.com/help/articles/4316](https://gitee.com/help/articles/4316).\)
60
61    ```
62    curl https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo
63    chmod a+x /usr/local/bin/repo
64    pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests
65    ```
66
672.  Download code repositories. \(There is no  **repo branch**  parameter.\)
68
69    ```
70    repo init -u https://gitee.com/openharmony/manifest.git -b master
71    repo sync -c
72    ```
73
74
75## Committing Code<a name="section338918220422"></a>
76
77## Committing a Repository \(git clone\)<a name="section669715742719"></a>
78
791.  **Update the branch.**
80
81    Update your local branch.
82
83    ```
84    git fetch origin
85    git checkout master
86    git pull --rebase
87    ```
88
89    Update the local debugging branch \(**myfeature**  branch\) based on the remote  **master**  branch.
90
91    ```
92    git branch myfeature origin/master
93    git checkout myfeature
94    ```
95
96    Then, edit and modify the code in the  **myfeature**  branch.
97
982.  **Commit the changes in the local working directory.**
99
100    ```
101    git add .
102    git commit -sm "xxxxxx"  // Commit changes with a message containing the signoff email address.
103    ```
104
105    You may continue to edit and test more content after the previous commit. You can use  **commit --amend**  to commit these changes.
106
1073.  **Push the changes to your remote directory.**
108
109    If you plan to review \(or just establish a remote backup of your work\), push the branch to your fork repository:
110
111    ```
112    git push -f origin myfeature
113    ```
114
115
116## Committing Multiple Repositories \(repo init/sync\)<a name="section6560046192910"></a>
117
1181. Configure the token of the global environment.
119
120```
121repo config --global repo.token {TOKEN}
122```
123
124The token is generated by choosing  **Settings**  \>  **Security Settings**  \>  [**Private Token**](https://gitee.com/profile/personal_access_tokens)  on Gitee. Example:
125
126```
127repo config --global repo.token 211XXXXXXXXXXXXXXXXXXXXXXXX
128```
129
1302. 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.\)
131
1323. Create a branch in the local code workspace, modify the code, and commit the changes.
133
134```
135repo start branchname --all
136```
137
138After the code is modified, run the following command in multiple repositories:
139
140```
141git add .
142git commit -sm "xxxxxx"
143```
144
145Alternatively, use the repo tool to batch add or commit the changes in the root directory of the code project:
146
147```
148repo forall -c 'git add .'
149repo forall -c 'git commit -sm "xxxxxx"'
150```
151
1524. Push the code. \(repo upload is not supported.\)
153
154Specify 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.
155
156```
157repo config repo.pullrequest {True/False}
158```
159
160For example, if the PR is generated when the push code is selected, run the following command:
161
162```
163repo config repo.pullrequest True
164```
165
166Run the following command to push the code:
167
168```
169repo push --br={BRANCH} --d={DEST_BRANCH} --content={PR_CONTENT}
170```
171
172**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:
173
174```
175repo push --br="20200903" --d="master" --content="#I1TVV4"
176```
177
178On the editing page displayed, open the comment tags for the repository, branch, and commit.
179
180![](figures/无标题2.png)
181
182Save 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.
183
184![](figures/无标题3.png)
185
186The tool automatically associates the PR with the issue.
187
188## Creating a Pull Request<a name="section28261522124316"></a>
189
190Access 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.\)
191
192For details, visit  [https://gitee.com/help/articles/4128](https://gitee.com/help/articles/4128).
193
194>![](public_sys-resources/icon-notice.gif) **NOTICE:**
195>**How do I create PRs at the same time if multiple code repositories have compilation dependencies?**
196>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:
197>1.  Create an issue in any of the code repositories.
198>2.  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](https://gitee.com/help/articles/4142).
199>3.  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.
200
201## Building Access Control<a name="section981124754415"></a>
202
203## Creating an Issue<a name="section979820334458"></a>
204
2051.  Go to the homepage of the repository.
2062.  Click the  **Issues**  tab in the upper left corner. Then, click the issue creation button on the right, and create a dedicated task as prompted to execute continuous integration \(CI\) access control for associated code \(feature development/bug fixing\).
207
208## Associating the Issue with the PR<a name="section5470144853615"></a>
209
210When 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.
211
212**Constraints**
213
214-   One PR can be associated with only one issue. Otherwise, CI cannot be triggered.
215-   If feature development or bug fixing involves multiple code repositories, multiple PRs can be associated with the same issue.
216-   Among the PRs associated with the issue, no PR that has been merged or closed is allowed. Otherwise, the CI cannot be triggered.
217-   If an issue has been associated with a merged or closed PR, the issue cannot be reused. In this case, create another issue and associate it with an open PR.
218
219## Triggering Code Access Control<a name="section11163175420406"></a>
220
221Comment "start build" in the PR to trigger CI access control.
222
223If multiple PRs are associated with the same issue, the comment "start build" on any PR can trigger the CI access control of the issue.
224
225After the access control is executed, the execution result will be automatically commented in all the PRs associated with the issue.
226
227If the access control is passed, all PRs associated with the issue will be automatically marked as "Passed".
228
229## CI Portal
230
231The continuous integration (CI) portal is a platform where you can promptly view and analyze the execution results of code access control and daily build.
232
233On 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:
234
235- 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.
236
237
238- 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.
239
240Visit [CI portal](http://ci.openharmony.cn/#/pipeLine).
241
242## Reviewing Code<a name="section17823849145014"></a>
243
244For details, visit  [https://gitee.com/help/articles/4304](https://gitee.com/help/articles/4304).
245
246Related topic:  [FAQs](faqs.md)
247
248