개발/gerrit
이 문서는 코드 리뷰 도구 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에 대한 더 많은 내용
- Gerrit에서 패치의 리뷰를 하는 방법은 Development/gerrit/PatchReview 를 확인하세오.
- gerrit으로 올린 후에 패치를 나누기, Split Patch after it was uploaded to gerrit
- Development/gerrit/CommonQueries
- 질문이 있나요? 우선 gerrit FAQ 를 먼저 참조하거나, 개발 메일링 리스트에 문의하시기 바랍니다. 또한 다음의 문서 공식 gerrit 문서 를 볼 수 있습니다.