패치 제출

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

기본 요건

먼저 다음을 완료했는지 확인하세요.

• 빌드 환경 초기화
• 소스 다운로드
• 비밀번호 생성기를 사용하여 비밀번호 생성
• 기여자 라이선스 계약 서명

리소스

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

Git 구성

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.

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

   

2. 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.

• done (checkmark icon): Approved by code owner
• clear (cross icon): Not approved by code owner
• access_time (clock icon): Pending approval by code owner

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.

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입니다. 대부분의 Bionic 코드는 BSD에서 가져옵니다. 따라서 변경사항이 Bionic의 새로운 코드에 적용되지 않는 한 업스트림 수정을 실행한 다음 적절한 BSD에서 완전히 새로운 파일을 가져옵니다.

Android 커널

모든 변경사항을 업스트림으로 만듭니다. 일반 안내는 Android 커널 기여 가이드라인 및 GKI용 커널 코드 개발 페이지를 참고하세요.

ICU

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

CLDR

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

LLVM/Clang/Compiler-rt

LLVM 컴파일러 인프라 페이지에서 LLVM 관련 프로젝트(external/clang, external/compiler-rt, external/llvm)에 관한 모든 변경을 실행합니다.

mksh

external/mksh에서 MirBSD Korn Shell 프로젝트에 관한 모든 변경을 실행합니다. mirbsd.org 도메인에서 miros-mksh로 이메일을 보내거나(구독 없이 제출 가능) Launchpad에서 할 수 있습니다.

OpenSSL

OpenSSL 페이지의 external/openssl에서 OpenSSL 프로젝트에 관한 모든 변경을 실행합니다.

V8

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

WebKit

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

zlib

zlib 홈페이지의 external/zlib에서 zlib 프로젝트에 관한 모든 변경을 실행합니다.