Skip to content

Merge requests

An agent opens them, a person lands them, with the whole history kept, and a way to undo one that has already landed.

Where
Merge requestsIn the app (sign-in required), opens in a new tab.
Reading time
2 min read

How it works

An agent opens a merge request; a person merges it. That button is the last place somebody reads a diff before it reaches a shared branch, and the rule is enforced for every caller rather than by each screen remembering to check.

Which branches a merge request may promote through is your organization's git flow: an ordered list of stages, where the first is what work is cut from, promotion runs left to right (a stage unlocks once the one before it has merged), and the last is production. A stage stores its key, not its branch name, so renaming the branch behind a stage leaves merge requests already opened against it intact.

History is kept. Waiting is the queue; All is everything ever opened. Only still-open rows are re-checked against the provider before the page answers, a merged merge request does not change again, and asking about a year of history would make the page unusable exactly as it got useful.

Reverting undoes one that has already landed. It is computed with real git in the workspace's own box, not through a provider API, GitHub's REST API has no revert at all, so a provider-based one would silently not exist for half the organizations using DevBench. Nothing is pushed to the target branch: the revert lands on revert/<repo>-<iid> and comes back as a merge request, so undoing a merge goes through the same review as making one.

Self-merge is a per-workspace opt-in, off everywhere by default, owner-only to change, and never available on an info-only workspace. Every self-merge is audited and announced to the organization, the point of the toggle is that the human read is skipped, so the team finds out it happened rather than discovering it later in the git history.

Steps

Following along? Tick each number off as you go.

  1. Open Merge requests in the top bar (or the search: Ctrl Ctrl, ⌘ ⌘ on a Mac).

    Waiting is what needs you; All is the full history.

  2. Press Review to read the change at your provider.

  3. Press Merge to land it.

    The next stage in the flow unlocks once this one is merged.

  4. To open one yourself, go to a workspace's Git tab, pick the branch to merge into, and press Create merge request.

    Push first, uncommitted work is not included.

  5. To undo one that has landed, use Revert on the merge request.

    You get a revert/… branch and a new merge request to review, not a push to the target branch.

  6. To let a workspace land its own work, an owner turns on self-merge in Settings → Git & merging on that workspace.

Commands

The same job from a workspace's box, for people who live in the terminal.

devbenchinside the box
  • $ devbench mr targetsThe stages --target accepts, and which are open.
  • $ devbench mr create --target <stage>Open merge requests promoting this workspace's branch.
  • $ devbench mr listThis workspace's merge requests, with ids.
  • $ devbench mr approve <mr_id>Land one, only where the workspace allows self-merge.
  • $ devbench mr reply <mr> <discussion> "…"Reply to a review thread.
  • $ devbench mr resolve <mr> <discussion>Resolve a review thread.

Read next

Code and shippingChanges and GitWhat is different since the workspace was checked out, whether it has reached the provider, and what the agent is allowed to push.Code and shippingReleasesCut one versioned release across every release-tracked repo: gate it, branch it, ship it and tag it.Running the organizationOrganization settingsThe defaults every workspace inherits: what its container is built with, the board's columns, the git flow, the agent and accounts boxes run on, and the standing instructions every agent reads.
Report a problem