Gerrit Workflow
To run a gerrit workflow, developers push single commits to a review branch. Reviewers check the change, vote on the patch, and merge it into main. Most engineering teams set up this process to guard their main code branches. When teams grant broad permissions, users can bypass code checks and push bad changes. Tight role rules keep the review flow safe and clean for all developers. How the native gerrit workflow operates Unlike branch-based tools, this system focuses on one single commit at
Agentic Workflow Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run a gerrit workflow, developers push single commits to a review branch. Reviewers check the change, vote on the patch, and merge it into main. Most engineering teams set up this process to guard their main code branches. When teams grant broad permissions, users can bypass code checks and push bad changes. Tight role rules keep the review flow safe and clean for all developers.
How the native gerrit workflow operates
Unlike branch-based tools, this system focuses on one single commit at a time. A developer writes code on a local machine and makes one commit. A special hook adds a unique change ID to the commit text. This ID tracks the change across every update during the review cycle. The developer then sends the commit to a virtual review ref.
The server reads the commit and opens a new review page for the team. Automated build bots pull the patch and run tests right away. These bots post a pass or fail score on the change page. Human reviewers also read the code and leave inline notes for the author. Reviewers give numerical scores to show if they approve the code change.
If the code needs a fix, the developer edits the local files. The developer amends the first commit instead of making a second commit. The unique change ID stays the same inside the commit note. Pushing the updated commit adds a new patch set to the same review. Once the patch gets top scores, an owner submits it to the main branch.
Managing permissions and roles in review projects
Project owners control who can read, push, score, and submit code changes. These rules live in a parent project and pass down to child repos. A normal developer role can upload patches and give low review scores. Senior leads get higher rights to give final approval scores and merge code. Bot accounts get their own role to post test results on patches.
Teams must keep direct push rights locked down on every main branch. If a role allows direct pushes, a user can skip the whole review step. Admins should also separate the right to approve code from the right to test. Auditing these project rules often helps teams spot wide permissions before mistakes happen.
Agentic Workflow Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What the native setup solves and where gaps remain
This review model stops unreviewed code from hitting your main source tree. It keeps the commit log clean and linear by avoiding messy merge commits. Every patch set stays on record, so teams can see how a change grew. Project roles also make sure that at least two pairs of eyes check code.
Still, code review rules only govern git pushes and branch updates. Once a change merges or an engineer fixes a bug, work moves to live systems. Developers and build runners must log in to servers and databases to run changes. Git roles decide who merges code, not what commands run on live servers later. Without controls on live sessions, an approved user can still run risky database queries. Teams also struggle to hide sensitive fields like emails or card numbers in query outputs.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does a patch set differ from a pull request?
A pull request compares a full branch with many commits against a target branch. A patch set is a single version of one commit tracked by an ID. Developers amend that single commit to update the review instead of adding new commits.
Why do commits need a change ID in the message?
Git creates a new hash every time a developer amends a local commit. The change ID stays in the commit text across all of those edits. This lets the review server link the new commit hash to the original review.
How can teams stop users from skipping code reviews?
Admins must remove direct push rights on target branches for all standard developer roles. All code updates must go through the virtual review namespace first. Only the review server should write to the main branch after scores pass.