이 페이지는 Cloud Translation API를 통해 번역되었습니다.

패치 제출

이 페이지에서는 검토를 요청하고 Gerrit를 사용하여 변경사항을 추적하는 방법을 포함하여 Android 오픈소스 프로젝트(AOSP)에 패치를 제출하는 전체 프로세스를 설명합니다. Gerrit는 Git을 사용하는 프로젝트를 위한 웹 기반 코드 검토 시스템입니다. Gerrit는 승인된 모든 사용자가 변경 사항을 제출할 수 있도록 허용함으로써 Git의 보다 중앙 집중화된 사용을 권장합니다. 변경 사항은 코드 검토를 통과하면 자동으로 병합됩니다. 또한 Gerrit를 사용하면 브라우저에 변경 사항을 나란히 표시하고 인라인 주석을 활성화하여 쉽게 검토할 수 있습니다.

전제 조건

시작하려면 다음을 수행했는지 확인하세요.

자원

Repo 및 Git에 대한 자세한 내용은 소스 제어 도구 페이지를 참조하세요.
Android 오픈소스 커뮤니티 내의 다양한 역할에 대한 자세한 내용은 프로젝트 역할 페이지를 참조하세요.
Android 플랫폼에 코드를 기여하는 방법에 대한 라이선스 정보는 라이선스 페이지를 참조하세요.

힘내 구성

Gerrit를 사용하려면 이메일이 등록된 Google 계정과 연결되어 있어야 합니다. 등록된 Google 계정과 연결된 이름 및 이메일 주소로 Git을 구성하려면 다음 명령어를 실행하세요.

git config --global user.name Your Name
git config --global user.email your_email@gmail.com

서버로 인증

다른 사용자와 IP 주소를 공유하는 경우 일반적인 사용 패턴에도 할당량이 적용될 수 있습니다. 예를 들어, 많은 사용자가 짧은 기간 내에 동일한 IP 주소에서 새 클라이언트를 동기화할 때 이런 일이 발생할 수 있습니다. 인증된 액세스는 IP 주소에 관계없이 각 사용자에 대해 별도의 할당량을 사용합니다. 인증된 액세스 활성화에 대해 읽으려면 인증 사용을 참조하십시오.

Repo 브랜치 시작

변경하려는 각 내용에 대해 관련 Git 저장소 내에서 새 분기를 시작하십시오.

repo start NAME .

You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and isn't included either on Gerrit or in the final source tree.

Make your change

Modify the source files, and test your changes.

For any changes made, follow License header best practices.

Commit your change

Commit the changes to your local repository with these commands:

git add -A
git commit -s

설명 변경

1행: 제목
한 줄 요약 제공( 최대 50자)
이 형식은 Git 및 Gerrit에서 다양한 디스플레이에 사용됩니다. 커밋 메시지에서 가장 중요하고 밀도가 높은 부분입니다. 변경한 영역을 설명하기 위해 접두사를 사용한 다음 이 커밋에서 변경한 내용을 설명하는 것을 고려해 보세요. 예를 들어 접두사로 ui 있는 경우입니다.
ui: Removes deprecated widget
2행: 공백
이 줄은 항상 비워두세요.
3행: 본문
이 줄부터 시작하여 더 긴 설명을 작성하세요.
최대 72자(영문 기준)로 하드 래핑해야 합니다. 변경으로 어떤 문제가 해결되는지, 어떻게 해결되는지 설명하세요. 이는 새로운 기능을 구현할 때 선택 사항이지만 나중에 다른 사람들이 특히 디버깅을 위해 이 변경 사항을 참조하면 매우 도움이 됩니다.
다른 기여자가 이 기능을 작업할 때 중요할 수 있는 가정이나 배경 정보에 대한 간략한 메모를 포함하세요.

repo init 중에 제공되는 고유한 변경 ID와 이름 및 이메일이 커밋 메시지에 자동으로 추가됩니다.

다음은 커밋 메시지의 예입니다.

Line 1, Headline - a short description

Line 3, Body - Add the detailed description of your patch here. Use as many lines
as needed. You can write an overall description, then list specifics.

I6e3c64e7a:Added a new widget.
I60c539a8f:Fixed the spinning image.

To read a blog about good commit descriptions (with examples), see How to Write a Git Commit Message by Chris Beams.

Upload to Gerrit

After you commit your change to your personal history, upload it to Gerrit with this command:

repo upload

If you started multiple branches in the same repository, you're prompted to select which ones to upload.

After a successful upload, Repo provides you with the URL of a new page on Gerrit. Click the link that Repo gives you to view your patch on the review server, add comments, or request specific reviewers for your patch.

Request a review

After you've uploaded your changes to Gerrit, the patch must be reviewed and approved by the appropriate code owners. Locate code owners in OWNERS files.

To find the appropriate code owners and add them as reviewers for your change, follow these steps.

Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.

Figure 1. Suggest owners link in Gerrit
Add code owners from the list as reviewers for your patch.

To determine the status of the files in your patch, check for the following icons next to the files in the patch.

(checkmark icon): Approved by code owner
(cross icon): Not approved by code owner
(clock icon): Pending approval by code owner

**Figure 2.** Example of files with icons showing code owner approval status

Upload a replacement patch

Suppose a reviewer looked at your patch and requested a small modification. You can amend your commit within Git, which results in a new patch on Gerrit that has the same change ID as the original.

Note: If you made other commits since uploading this patch, you must manually move your Git HEAD.

git add -A
git commit --amend

수정된 패치를 업로드하면 Gerrit와 로컬 Git 기록 모두에서 원본이 대체됩니다.

동기화 충돌 해결

자신의 패치와 충돌하는 다른 패치가 소스 트리에 제출된 경우 소스 저장소의 새 HEAD 위에 패치를 리베이스하세요. 이렇게 하려면 다음 명령을 실행하세요.

repo sync

repo sync 명령은 소스 서버에서 업데이트를 가져온 다음 자동으로 HEAD 새 원격 HEAD 로 리베이스하려고 시도합니다.

자동 리베이스가 실패하면 수동 리베이스를 수행합니다.

repo rebase

리베이스 충돌을 처리하는 또 다른 도구는 git mergetool 입니다. 충돌하는 파일을 성공적으로 병합한 경우 다음 명령을 실행하세요.

git rebase --continue

자동 또는 수동 리베이스가 완료된 후 repo upload 실행하여 리베이스된 패치를 제출하세요.

제출이 승인된 후

제출이 검토 및 확인 프로세스를 거친 후 Gerrit는 변경 사항을 자동으로 공용 저장소에 병합합니다. 다른 사용자는 repo sync 실행하여 해당 로컬 클라이언트로 업데이트를 가져올 수 있습니다.

업스트림 프로젝트의 경우

Android는 Android 소프트웨어 관리 에 설명된 대로 Linux 커널 및 WebKit과 같은 다양한 오픈소스 프로젝트를 활용합니다. external/ 아래에 있는 대부분의 프로젝트의 경우 업스트림으로 변경한 다음 Android 유지 관리 담당자에게 변경 사항이 포함된 새로운 업스트림 릴리스를 알립니다.

새로운 업스트림 릴리스를 추적하게 하는 패치를 업로드할 수도 있습니다. 일반적으로 릴리스마다 업그레이드되는 아래에 언급된 대부분의 대규모 프로젝트처럼 프로젝트가 Android 내에서 널리 사용되는 경우 변경하기 어려울 수 있습니다.

흥미로운 특별한 사례 중 하나는 Bionic입니다. 대부분의 코드는 BSD에서 가져온 것이므로 Bionic의 새로운 코드에 대한 변경 사항이 아닌 한 업스트림 수정을 수행한 다음 해당 BSD에서 완전히 새로운 파일을 가져오십시오.

안드로이드 커널

모든 변경을 업스트림으로 수행합니다. 일반적인 지침은 Android 커널 기여 지침 및 GKI용 커널 코드 개발 페이지를 따르세요.

중환자실

ICU-TC 홈 페이지 의 external/icu ( icu4c/ 및 icu4j/ 폴더)에서 ICU 프로젝트를 모두 변경합니다. 자세한 내용은 ICU 버그 및 기능 요청 제출을 참조하세요. 모든 업스트림 Jira 요청에 'android' 라벨을 추가합니다.

CLDR

ICU의 대부분의 언어 데이터는 유니코드 CLDR 프로젝트 에서 나옵니다. CLDR에 기여 에 따라 모든 요청 업스트림을 제출하고 'android' 라벨을 추가하세요.

LLVM/Clang/컴파일러-rt

LLVM 컴파일러 인프라 페이지 에서 LLVM 관련 프로젝트( external/clang , external/compiler-rt , external/llvm )를 모두 변경하세요.

mksh

mirbsd.org 도메인의 miros-mksh 로 이메일을 보내거나(제출하는 데 가입이 필요하지 않음) 또는 Launchpad 에서 external/mksh 의 MirBSD Korn Shell 프로젝트에 대한 모든 변경 사항을 적용하세요.

OpenSSL

OpenSSL 페이지 의 external/openssl 에서 OpenSSL 프로젝트를 모두 변경합니다.

V8

V8 이슈 페이지 의 external/v8 에서 V8 프로젝트에 대한 모든 변경 사항을 제출하세요. 자세한 내용은 V8에 기여하기를 참조하세요.

웹킷

WebKit 페이지 의 external/webkit 에서 WebKit 프로젝트를 모두 변경하세요. WebKit 버그를 제출하여 프로세스를 시작하세요. 버그에서는 버그가 Android 와 관련된 경우에만 플랫폼 및 OS 필드에 Android를 사용하세요. 버그는 제안된 수정 사항이 추가되고 테스트가 포함된 후에 검토자의 관심을 받을 가능성이 훨씬 더 높습니다. 자세한 내용은 WebKit에 코드 기여를 참조하세요.

zlib

zlib 홈 페이지 의 external/zlib 에서 zlib 프로젝트를 모두 변경합니다.