Patch Guru가 되는 방법?¶

새로운 기능을 구현하거나 이미 존재하는 기능에 문서를 추가하는 작업을 할 때, 작업 자체에 휩쓸리거나 변경 사항 구성성의 불문율을 잊어 버리기 쉽습니다.

이 섹션에서는 사람들이 리뷰하고 싶은 패치를 만드는 방법을 안내합니다.

다음을 수행 할 수 있습니다:

검토 프로세스 전반에 걸쳐 유지 관리가 더 용이하도록 패치를 구성하는 방법을 알고 있습니다.
커뮤니티 구성원이 보다 쉽게 검토 할 수 있도록 패치를 구성하는 방법을 알고 있습니다.

적절한 크기¶

큰 패치를 검토하는 것은 매우 불편하고 시간이 많이 걸리므로, 항상 변경사항을 작은 블록단위로 나누는 것이 좋습니다.

변경 사항의 크기를 최대한 작게 유지 하는 것에 대한 매직 넘버는 없지만 총 수백 줄 미만으로 변경됩니다. 코드 변경이 거의없이 테스트가 많은 패치는 코드 변경만큼 많은 노력이 필요합니다.

드문 경우지만 변경에 대한 좋은 논리적 분석이 없고 패치가 천 줄 이상으로 늘어날 수 있습니다. 예를 들어 다른 패치에 대한 관련 테스트 변경 사항을 추출 할 수 없기 때문에 어떤 경우에는 허용되지만 권장되지는 않습니다.

하위 계층의 공통 기능에 의존하지 않는 기능의 논리적 부분이나 문서와 같은 다른 패치로 가능한 한 많이 추출하십시오.

패치가 길수록 검토하는 데 더 많은 시간이 필요합니다. 가능하면 길이를 합리적으로 유지하십시오. 불가능한 경우 코드 주석을 추가하고 패치에 도입한 변경사항을 설명하는 자세한 커밋 메시지를 작성하여 검토자를 도울 수 있습니다.

패치 체인, 의존 태그 및 Gerrit 주제들¶

복잡한 기능 구현 작업의 경우, 동일한 프로젝트 또는 여러 프로젝트의 여러 모듈에 변경 사항을 도입해야 할 때 종속성 관리에 매우 주의해야 합니다.

디자인 구조에 따라 선택할 수 있는 여러 옵션이 있습니다. 패치 체인의 변경사항을 구성하거나 ‘Depends-On’ 태그를 사용할 수 있습니다.

종속(Depends-On) 태그¶

여러 프로젝트 저장소에 변경 사항이 있는 경우 ‘Depends-On’ 태그로 종속 패치를 표시 할 수 있습니다. 태그는 커밋 메시지에 링크로 표시되어 사용자와 검토자가 변경 사항의 종속성을 추적하고 탐색하는 데 도움이 됩니다.

‘Depends-On’ 태그는 변경 사항에 대한 마커로, 사용시 모든 종속성이 떨어질 때까지 패치를 병합 할 수 없습니다.

태그는 동일한 저장소에 대해 제안된 패치에도 적용할 수 있습니다. 이 경우 변경 사항은 독립적으로 유지될 수 있을 만큼 분리되어 있으므로 리뷰 코멘트에서 변경 사항을 수정해야 하는 경우 패치별로 수행할 수 있습니다. 각 패치를 리베이스하는 경우에도 마찬가지입니다.

참고

‘Depends-On’ 태그를 사용하는 경우 기능 구현 또는 문서 변경에 대한 모든 변경 사항을 다운로드하여 기능을 테스트하거나 모든 변경 사항이 적용된 문서를 빌드해야 합니다. 이 경우 Git은 종속성을 자동으로 처리하지 않습니다.

패치 체인¶

어떤 경우에는 필요한 변경사항을 소규모 블록으로 세분화할 때, 변경사항 사이에 독립적 변경을 방지하는 직접적인 종속성을 피할 수 없는 경우도 있습니다. 이러한 변경 사항에 대해 작업할 때 추가 주의가 필요한 종속성을 유지하려면 체인에 변경 사항을 정리해야 합니다.

패치 체인이 있는 경우에도 릴리즈에 맞춰 두 패치가 모두 도착한다고 보장할 수 없기 때문에, 코드 변경 및 관련 테스트를 하나의 패치에 보관해야 합니다.

체인이 있는 경우 Gerrit은 Gerrit UI의 오른쪽 상단 모서리에 있는 ‘관련 변경 사항’ 열에 모든 커밋 제목을 나열하면 도움이 됩니다. 제목은 새 버전을 업로드할 때 검토하기 위해 변경 사항 사이를 탐색하는 데 도움이 되는 링크입니다.

어떻게 체인을 다룰 수 있습니까?¶

몇가지 권장 사항을 염두해두면 패치 체인을 다루기 쉬울 것입니다:

다른 기능이나 버그 수정과 관련된 변경 사항과 함께 혼동하지 않도록 이러한 변경 사항에 대한 로컬 브런치를 항상 확인하십시오.
체인을 항상 전체 체인을 다시 생성하여 하나의 변경 블록으로 처리하고 패치를 수정하여 검토 주석을 수정하거나 체인에 변경사항을 추가할 때 체인을 최신 상태로 유지합니다.
체인 내에서 패치를 수정하려면 interactive rebase를 사용해야합니다:

git rebase -i HEAD^

체인 상단에서 편집할 패치 번호만큼 ‘^’ 이 필요합니다. 아니면 git-restack 를 사용하여, 적절한 git rebase 명령어를 파악할 수 있습니다.

또한 Gerritt는 패치 자체를 편집하거나 커밋 메시지만 편집하는 옵션과 작성자 수정과 같은 고급 변경 사항에 대한 몇 가지 추가 옵션을 제공합니다.

전체 체인을 다운로드하려면 상단 패치를 다운로드해야 하며 Git은 체인의 모든 종속 패치를 자동으로 다운로드합니다.
개별 패치를 업데이트하는 것과 동일한 방식으로 체인의 상위 패치만 수정하면 되는 경우입니다.
체인에 변경 사항을 업로드하면 업데이트된 패치만 업로드됩니다. 이는 체인의 하위 패치에 대한 검토 점수가 변경되지 않음을 의미하기도 합니다.
패치가 개별적으로 병합되고 전체 체인이 동시에 도착한다는 보장이 없으므로 항상 각 패치의 변경 사항을 확인하고 오른쪽 패치의 변경 사항을 적용했는지 확인합니다.

패치 체인 관리에 대한 자세한 내용은 튜토리얼 : 시리즈에서 변경 사항 개발 을 참조하시기 바랍니다.

게릿 주제¶

검토를 위해 변경사항을 업로드할 때 변경사항을 지정할 수 있습니다. 게리트 항목은 패치에 종속성을 추가하지 않지만, 동일한 주제를 가진 패치가 있는 모든 프로젝트의 모든 관련 변경 사항을 보여주는 항목을 기반으로 검색을 적용할 수 있습니다. 게리트는 또한 검토 페이지의 오른쪽 상단 모서리에 있는 ‘Same Topic’ 열에 해당 항목을 표시합니다.

이렇게 하면 기능 구현, 버그 수정 또는 문서화 작업을 비롯하여 관련 변경 사항을 추적할 수 있습니다.

어떻게 하면 변화를 구조화할 수 있을까요?¶

작업 항목이 특정 크기 이상으로 커지고 여러 패치를 업로드해야 하는 경우 패치 체인과 독립적 변경의 경우 해당 패치를 잘 구성해야 합니다.

OpenStack Compute의 경우 가상 드라이버 변경, 컴퓨팅 관리자 및 API 변경과 같이 프로젝트의 모듈별로 변경 사항을 그룹화하는 것이 좋습니다.

모듈별 변경사항을 그룹화하여 구성 요소의 계층별로 체인 또는 종속성을 구성하고 API 변경사항을 항상 최신 상태로 유지할 수 있습니다. 따라서 새로운 기능이 활성화되며 이러한 변경사항은 설계에 필요한 다른 모든 항목에 따라 달라집니다.

이 외에도 더 작은 빌딩 블록을 찾고 변경 사항을 더 작게 만드는 기능을 살펴볼 수도 있습니다. 예를 들어 나중에 새 API 기능을 구현할 때 사용할 개체 변경 사항을 먼저 구현할 수 있습니다.

변경 사항을 구조적으로 분할¶

좋은 커밋을 만들기 위한 기본 규칙은 커밋당 오직 하나의 “논리적 변경”이 있는지 확인하는 것입니다. 이것이 중요한 규칙인 데에는 여러가지 이유가 있습니다.

변경되는 코드의 양이 적을수록, 잠재적인 결함을 더 쉽고 빠르게 검토하고 식별할 수 있습니다.
나중에 변경 사항에 결함이 있는 것으로 밝혀지면, 결함이 있는 커밋을 되돌려야 할 수도 있습니다. 이 때 커밋에서 변경하고자 했던 것과 관련 없는 코드가 없다면, 훨씬 더 쉽게 수행할 수 있습니다.
Git의 Bisect 기능을 사용하여 문제를 해결할 때, 작은 단위로 잘 정의된 변경 사항은 코드 문제가 발생한 정확한 위치를 분리해내는 데 도움이 됩니다.
``git annotate``나 ``git blame``을 사용하여 커밋 히스토리를 검색할 때, 변경 사항을 작은 단위로 잘 정의하는 것은 코드 조각이 어디서부터 왔고 왜 작성 되었는지 정확하게 분리해내는 데 도움이 됩니다.

올바른 컨텐츠¶

기능 구현 또는 버그 보고서와 관련이 없는 변경사항은 업로드할 수 있지만 검토자는 이를 환영하지 않습니다.

코드 또는 설명서의 개선은 문서화에서 오타를 수정하려는 경우 전체 가이드와 같이 더 큰 블록에 대해 수행해야 하는 것과 같은 큰 노력의 일환이어야 합니다. 나중에 추적할 수 있는 이와 같은 작업 항목에 대한 작업이 있는 스토리를 보고하는 것도 선호됩니다.

이는 코드 개선과 유사합니다. 커뮤니티가 크고 전 세계에 걸쳐 있기 때문에 우리는 코딩 가이드라인을 가지고 있지만, 각 개인의 스타일은 여전히 매우 다를 수 있습니다. 우리는 특정한 코딩 방식을 강요하지 않습니다. 따라서 환영받지 못하며 매우 의견 있는 논쟁의 근원이 되는 수정과 관련된 변경은 피해야 합니다.

구조 조정 방법 및 사용되지 않은 코드 스니펫을 삭제하여 코드를 읽기 쉽고 쉽게 유지관리할 수 있는 코드 리팩터링 작업의 경우 프로젝트 팀과 협의하여 스토리보드에 먼저 보고한 후 관련 변경 사항을 Gerrit에 업로드하여 검토하도록 적극 권장합니다.

Patch Guru가 되는 방법?