Advanced Features

Master priority lanes, admin controls, runtime authorization, and advanced lane management for your team.

Understanding Priority Lanes

GitQueue uses five priority lanes to manage merge order. Each lane has explicit access controls and enqueue rules, allowing you to prioritize critical work while maintaining quality standards.

Processing order: highest → high → normal → low → lowest. Within each lane, PRs are processed first-in, first-out.

All Five Priority Lanes

LaneCommandAccess RequiredGate Requirements
Highest/gitqueue add highestAdmin onlyChecks, Approval, and Freshness must be pass or warn
High/gitqueue add highCODEOWNERSChecks, Approval, and Freshness must be pass or warn
Normal/gitqueue add normalWrite accessChecks, Approval, and Freshness must be pass or warn
Low/gitqueue add lowWrite accessChecks, Approval, and Freshness must be pass or warn
Lowest/gitqueue add lowestWrite accessPending, warn, or pass is allowed

Detailed Lane Information

Highest Lane

Emergency lane for critical production fixes. Only repository admins can add PRs to this lane.

Use cases: Production hotfixes, critical security patches, urgent rollbacks

High Lane

High-priority lane reserved for repository CODEOWNERS. Perfect for important features or significant changes.

Use cases: Major features, architectural changes, important bug fixes

Normal Lane (Default)

Standard feature development lane. Most PRs should use this lane.

Use cases: Feature development, bug fixes, refactoring, documentation updates

Low Lane

Lower priority for non-urgent improvements. Non-lowest gate rules still need to be satisfied to enqueue here.

Use cases: Minor improvements, code cleanup, non-critical updates

Lowest Lane

Accepts PRs whose gates are still pending or warming up. Use for work in progress before it is ready for a non-lowest lane.

Use cases: WIP changes, experimental features, PRs waiting for reviews

Gate Requirements: To add a PR to highest, high, normal, or low lanes, Checks, Approval, and Freshness must each be pass or warn. The lowest lane is the exception for PRs that are still pending.

Using Highest Lane for Hotfixes

The highest lane is designed for emergency situations where you need to merge a fix immediately. It bypasses all queued PRs in lower-priority lanes.

When to Use Highest Lane

  • Production is down or severely degraded
  • Critical security vulnerability needs immediate patching
  • Data loss or corruption is occurring
  • Urgent rollback is required

Hotfix Workflow

  1. Create hotfix branch from the default branch with your critical fix
  2. Open PR and ensure Checks, Approval, and Freshness are already pass or warn
  3. Add to highest lane with /gitqueue add highest
  4. Watch it merge as soon as the three processing gates pass

Important: Even highest lane PRs must satisfy non-lowest enqueue rules and still pass Checks, Approval, and Freshness during processing. GitQueue prioritizes safety over speed.

Admin Controls

Repository admins have access to additional commands for managing merge lane processing and clearing lanes.

Block/Unblock Repository

Temporarily pause merge lane operations for a repository. Useful during deployments, maintenance windows, or when investigating issues.

CommandDescription
/gitqueue blockBlocks new enqueue commands and pauses all processing. PRs stay in their lanes until a repository admin unblocks the repository.
/gitqueue unblockResumes enqueue and processing so queued PRs can continue through normal lane selection.

Common Use Cases

  • • Block during production deployments to prevent conflicts
  • • Block during database migrations or infrastructure changes
  • • Block when investigating test flakiness or CI issues
  • • Block during planned maintenance windows

Clear Queues

Remove all PRs from specific lanes or all lanes at once. Affected PRs are reset to a non-queued state, so this should be used carefully.

CommandDescription
/gitqueue clear highestClear all PRs from the highest lane
/gitqueue clear highClear all PRs from the high lane
/gitqueue clear normalClear all PRs from the normal lane
/gitqueue clear lowClear all PRs from the low lane
/gitqueue clear lowestClear all PRs from the lowest lane
/gitqueue clear allClear all PRs from all lanes

Use With Caution: Clearing queues removes PRs from merge lanes and returns their overview comments to general mode. They will need to be manually re-added with /gitqueue add commands. This is typically used when reorganizing priorities or resolving issues.

Permissions

GitQueue uses GitHub's permission system to control access to lanes and admin commands at command execution time.

Permission Levels

RoleCan Add to LanesCan Use Admin Commands
Repository AdminAll lanesYes (block, unblock, clear)
CODEOWNERShigh + write lanesNo
Write Accessnormal, low, lowestNo

Repository Admins

Can use all commands: add/remove to any lane, clear lanes, block/unblock repository

CODEOWNERS

Can add PRs to the high lane. Normal, low, and lowest still follow the repository's ordinary write-access rules.

Write Access Users

Can add/remove PRs to normal, low, and lowest lanes, and can remove their own PRs from any lane

Runtime authorization matters: GitQueue checks permissions when each command runs. A PR that was queued earlier can still be rejected for later actions if the actor no longer has the required repository access.

Best Practices

Follow these recommendations to get the most out of GitQueue's advanced features while maintaining team productivity.

Use Normal Lane by Default

Most PRs should use the normal lane. Reserve higher priorities for truly urgent work to prevent priority inflation.

Document Highest Lane Usage

Establish team guidelines for when to use the highest lane. Consider requiring incident tracking for highest lane PRs to ensure proper documentation.

Coordinate Repository Blocking

Communicate with your team before blocking the repository. Use team chat to announce blocks and estimated duration to avoid confusion.

Use Lowest Lane for Pending Work

The lowest lane is useful for WIP PRs or changes whose gates are still pending. It keeps them separate from production-ready work.

Monitor Queue Health

Regularly review queue status to identify bottlenecks. If PRs are frequently failing gates, investigate CI configuration or review processes.

Clear Queues Sparingly

Use the clear command only when necessary, such as after major infrastructure changes or when reorganizing priorities. Always communicate with affected contributors.

Next Steps