As I mentioned in an earlier post, Gerrit has a unique workflow. It has some similarities to pull and merge request models, but is more flexible and more automated. That goes back to its roots in the Android ecosystem; at the scale of work in that community, bottlenecks need to be few and far between.
Gerrit’s model is unique in a couple of ways:
- By default all changes are put into temporary pending review branches, which are created automatically on push.
- The workflow engine enforces rules before changes can be merged to the permanent repository. Notably, you can require human code review, automated build and test, or both, and use the access control system to specify who’s allowed to perform various steps in the workflow.
- Review IDs are generated automatically via hooks and group serial sets of patches. Additional patches can be provided for rework based on the result of a review.
- Gerrit’s Prolog engine can be used to create customized review approval conditions.
Gerrit’s workflow engine is well tuned for ‘continuous review’, which means that commits can be reviewed rapidly and merged into trunk (master or mainline) very quickly. In some cases only certain commits would be manually reviewed, while all commits would be subject to automated build and test. Gerrit is thus a good choice for large scale deployments that want to move towards continuous delivery practices.