개발/gerrit

    From The Document Foundation Wiki
    This page is a translated version of the page Development/gerrit and the translation is 71% complete.

    이 문서는 코드 리뷰 도구 gerrit.libreoffice.org 와 리브레오피스에서 어떻게 코드 리뷰를 사용하는지에 대한 문서입니다.

    Gerrit을 위한 설정

    Gerrit을 위한 설정(영문) 문서를 보십시오.

    대안은 수동 접근으로 조작을 하는 것입니다. 상세한 내용은 다음의 링크 Setting yourself up for gerrit - the manual way 에서 확인 가능합니다.

    Gerrit으로 패치 전달하기

    다음의 링크 gerrit으로 리뷰를 위해 패치를 제출하기 (영문) 를 보시기 바랍니다,

    다음의 문서 Submit a patch for review with gerrit 에서는 다음의 주제에 대한 논의를 찾을 수 있습니다:

    • 새로운 버전 제출하기
    • 초안(drafts)으로 패치(patches) 제출하기

    다음의 문서 Submodules 에서는 다음과 같은 서브모듈(submodules)에 패치 제출에 대한 논의를 찾을 수 있습니다.

    • dictionaries [사전]
    • helpcontent2 (for help files) [도움말]
    • translations [번역]

    Gerrit workflow compared to GitHub/GitLab

    The workflow with Gerrit patches is just as simple as GitHub/GitLab pull/merge requests, having only a different approach. With GitHub/GitLab PRs/MRs, you work in a branch and your additional changes will appear as a series of commits. With a Gerrit patch, you keep amending a single commit and your changes will appear as a series of patch sets. In addition to this, for bigger projects it is possible to create a series of patches that depend on each other (Related changes) or even to create remote feature branches.

    Gerrit documentation has a Basic Gerrit walkthrough for GitHub users.

    Gregory Szorc has written an essay about the problems with the GitHub/GitLab patch model. It touches upon Gerrit as well:

    An interesting outlier is Gerrit, which ingests its integration requests via git push. But the way Gerrit's ingestion via git push works is fundamentally different from how pull requests work! With pull requests, you are pushing your local branch to a remote branch and a pull request is built around that remote branch. With Gerrit, your push command is like git push gerrit HEAD:refs/for/master. For the non-gurus, that HEAD:refs/for/master syntax means, push the HEAD commit (effectively the commit corresponding to the working directory) to the refs/for/master ref on the gerrit remote (the SOURCE:DEST syntax specifies a mapping of local revision identifier to remote ref). The wizard behind the curtain here is that Gerrit runs a special Git server that implements non-standard behavior for the refs/for/* refs. When you push to refs/for/master, Gerrit receives your Git push like a normal Git server would. But instead of writing a ref named refs/for/master, it takes the incoming commits and ingests them into a code review request! Gerrit will create Git refs for the pushed commits. But it mainly does that for its internal tracking (Gerrit stores all its data in Git - from Git data to review comments). And if that functionality isn't too magical for you, you can also pass parameters to Gerrit via the ref name! e.g. git push gerrit HEAD refs/for/master%private will create a private review request that requires special permissions to see. (It is debatable whether overloading the ref name for additional functionality is a good user experience for average users. But you can't argue that this isn't a cool hack!)

    Gerrit에 대한 더 많은 내용

    더 읽어보기