| --- |
| title: " How Gerrit Works" |
| sidebar: userguide_sidebar |
| permalink: alpha-intro-how-gerrit-works.html |
| --- |
| {% include important.html content="This content is currently in <b>alpha</b>. It |
| is still under review." %} |
| |
| To understand how Gerrit fits into and enhances the developer workflow, |
| consider a typical project. This project has a central source |
| repository, which serves as the authoritative copy of the project’s |
| contents. |
| |
|  |
| |
| Gerrit takes the place of this central repository and adds an additional |
| concept: a *store of pending changes*. |
| |
|  |
| |
| With Gerrit, when a developer makes a change, it is sent to this store |
| of pending changes, where other developers can review, discuss and |
| approve the change. After enough reviewers grant their approval, the |
| change becomes an official part of the codebase. |
| |
| In addition to this store of pending changes, Gerrit captures notes and |
| comments about each change. These features allow developers to review |
| changes at their convenience, or when conversations about a change can’t |
| happen face to face. They also help to create a record of the |
| conversation around a given change, which can provide a history of when |
| a change was made and why. |
| |
| Like any repository hosting solution, Gerrit has a powerful [access |
| control model](access-control.html). This model allows you to fine-tune |
| access to your repository. |
| |