패치 제출

이 페이지에서는 Gerrit로 변경사항을 검토 및 추적하는 과정을 포함하여, Android 오픈소스 프로젝트(AOSP)에 패치를 제출하는 전체 과정을 설명합니다.

기본 요건

기여자

서버로 인증

Gerrit에 업로드하려면 먼저 서버에서 본인을 식별할 수 있도록 비밀번호를 생성해야 합니다. 비밀번호 생성기 페이지의 안내를 따르세요. 비밀번호는 한 번만 생성하면 됩니다. 자세한 내용은 인증 사용을 참조하세요.

Repo 브랜치 시작

적용하려는 각 변경사항에 관해 관련 Git 저장소 내에서 새 브랜치를 시작합니다.

    repo start NAME .
    

같은 저장소에서 여러 개의 독립적 브랜치를 동시에 시작할 수 있습니다. 브랜치 NAME은 작업공간 기준에서 로컬이며, Gerrit 또는 최종 소스 트리에 포함되지 않습니다.

변경하기

소스 파일을 수정하고 확인한 후 로컬 저장소에 변경사항을 커밋합니다.

    git add -A
    git commit -s
    

커밋 메시지에서 변경사항에 관한 상세한 설명을 제공합니다. 이 설명은 공개 AOSP 저장소로 푸시되므로 변경 목록 설명 작성에 관한 다음 가이드라인을 따르시기 바랍니다.

  • 먼저 한 줄 요약(최대 50자)을 작성하고 빈 행을 추가합니다. 이 형식은 Git 및 Gerrit에 의해 다양한 표시 용도로 사용됩니다.

  • 세 번째 행부터는 더 긴 설명을 입력합니다. 최대 72자에서 강제 줄바꿈을 해야 합니다. 변경사항이 어떤 문제를 어떻게 해결하는지 설명합니다. 두 번째 부분은 새로운 기능 구현 시의 선택사항에 가깝지만 실행하는 것이 좋습니다.

  • 다른 기여자가 이 기능으로 작업할 때 중요할 수 있는 모든 가정에 관한 간단한 참고사항이나 배경 정보를 포함합니다.

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

Short description on first line

    More detailed description of your patch,
    which is likely to take up multiple lines.
    

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

Gerrit에 업로드

변경사항을 개인 기록에 커밋한 후에는 다음을 사용하여 Gerrit에 업로드합니다.

    repo upload
    

동일한 저장소에서 여러 브랜치를 시작한 경우 업로드할 브랜치를 선택하라는 메시지가 표시됩니다.

업로드에 성공하면 Repo는 Gerrit의 새 페이지 URL을 제공합니다. 이 링크를 방문하여 수신 서버에 관한 패치를 보거나 의견을 추가하거나 구체적인 패치 검토자를 요청할 수 있습니다.

교체 패치 업로드

검토자가 패치를 살펴본 후 약간의 수정을 요청했다고 가정해 보겠습니다. Git 내에서 커밋을 수정할 수 있으며, 이렇게 할 경우 원본과 동일한 변경 ID와 함께 Gerrit에 관한 새 패치가 생성됩니다.

    git add -A
    git commit --amend
    

수정된 패치를 업로드하면 이 패치가 Gerrit 및 로컬 Git 기록의 원본을 대체합니다.

동기화 충돌 해결

본인의 것과 충돌하는 소스 트리에 다른 패치가 제출되면 소스 저장소의 새로운 HEAD 위에 패치를 리베이스해야 합니다. 가장 쉬운 방법은 다음을 실행하는 것입니다.

    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에서 완전히 새로운 파일을 풀링하는 것이 바람직합니다.

ICU4C

ICU-TC 홈페이지external/icu4c에서 ICU4C 프로젝트에 관한 모든 변경을 실행합니다. 자세한 내용은 ICU 버그 및 기능 요청 제출을 참조하세요.

LLVM/Clang/Compiler-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

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

zlib

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