[ English | 한국어 (대한민국) | 中文 (简体, 中国) | Indonesia | English (United Kingdom) | español (México) | Deutsch ]

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에 업로드하여 검토하도록 적극 권장합니다.