Autonomous merge

By default an agent run stops at a pull request and waits for you. Autonomous merge changes the last step: once your own rules allow the merge, Taiga presses the button instead of waiting.

Nothing else about the run changes. The agent still plans, builds, pushes and opens a pull request the same way, and the pull request is still an ordinary one in your repository.

Taiga merges through your rules, never around them

This is the part worth understanding before you turn it on.

Taiga asks your source-control provider whether the pull request may merge, and respects the answer. The merge is an ordinary API call that your branch protection evaluates exactly as it would for any other contributor. If your rules require an approving review, a passing check, an up-to-date branch or a resolved conversation, the merge waits for it.

Taiga never asks to be a bypass actor on your repository, and never requests an exception to a rule you set. A refusal from your rules is an answer Taiga records and reports, not an obstacle it works around.

The merge itself uses a method your repository allows. Taiga prefers a merge commit, then a rebase, then a squash, in that order, because each step down that list keeps less of the work’s history in your repository. If your repository only allows squash merging, Taiga squashes; you never need to configure this. When it squashes, the merge commit’s description is the pull request’s description, so what lands in your history is the summary you reviewed rather than a list of the agent’s working commits.

The practical consequence: auto-merge can only ever merge something you would have been allowed to merge yourself. It cannot widen what your repository permits. It only removes the wait.

Who does the merging

The merge is made by the Taiga GitHub App you installed on the repository, using that installation’s own credentials. Your repository’s history and your audit trail show the app as the merger, not a person, and not the person whose work it was. Whoever started the run is recorded as the work’s author, in Taiga’s own audit log and on the run, but they are never made to appear as if they pressed merge.

Autonomous merge works on GitHub today, including GitHub Enterprise. A project whose repository lives on another provider keeps the ordinary behavior: the run opens its pull request and waits for you, and the initiative says that Taiga cannot merge there yet.

Turning it on

Autonomous merge is off until you switch it on, and the switch that opens it is at the organization level.

Go to Organization settings, find Autonomy, and turn on Allow merging on its own. Turning it off stops Taiga merging anything, immediately, everywhere in the organization. Pull requests already open stay open and become yours to merge as before.

Teams, projects and initiatives

Below the organization there are two ceilings and one default, and the difference matters.

Your organization and your teams are ceilings. Turning autonomous merge off at either stops it for everything underneath, and nothing below can turn it back on. A team that turns it off stops autonomous merges for every project and initiative under it.

A project sets a default, not a rule. Its switch decides what initiatives in that project do when nobody has decided for them. An individual initiative can still be switched on even where its project defaults to off, which is how you let one piece of work merge itself without reopening the whole project.

An initiative’s own switch is the final word, within what your organization and teams allow. It lives on the initiative’s cockpit under Autonomy, as Merge on its own. Leaving it untouched means it follows the project’s default; touching it makes a decision that later changes to that default no longer override.

If you cannot turn autonomous merge on somewhere, your organization or a team has turned it off above, and that is where to change it. Most organizations only ever touch the top one.

Making Taiga wait for your code reviewer

If you run your own automated reviewer, whether that is GitHub Copilot, CodeRabbit, Greptile or anything else, you decide whether Taiga waits for it.

Add that reviewer as a required status check on the branch. Your provider then blocks the merge until the reviewer reports, and Taiga waits with it, because Taiga is reading your provider’s answer rather than forming its own.

Anything you have not made required is treated as advisory. Taiga does not try to detect which tools you have installed or guess which of their opinions you meant to be binding. That is deliberate: a tool that guessed would eventually guess wrong, and the setting that decides it is one you already control.

The same applies to human review. If your branch protection requires an approval, auto-merge waits for a person to give it, then merges once the rest of your rules are satisfied.

Seeing why a merge has not happened

When auto-merge is on but a pull request has not merged, the initiative says why.

The reason appears on the initiative, under the pull request state, and names the specific thing that is blocking it: a review that is still owed, a check that is still running or failing, a branch that conflicts with its base, or a rule in your repository that refused.

Two kinds of reason are worth telling apart, and the panel does:

• Waiting means the block clears on its own. A check finishing, a review arriving. Taiga merges as soon as it does.
• Stopped means it does not. A merge conflict will not resolve itself, and a closed pull request will not reopen.

Waiting is not forever, but it restarts whenever a review arrives. If a block that should clear on its own has not cleared after about an hour of quiet, Taiga stops trying and says so, and the pull request stays yours to merge by hand.

That hour counts quiet, not total time. Every review submitted on the pull request gives Taiga a fresh hour, however long the pull request has been open, so a review left until the next morning or the next week still merges when it arrives.

The usual cause of a real stop is a required check that never reports, which nothing but a person can fix — and when that happens, Taiga names the check. If your rules require something nothing in the repository produces, say a code scanning tool that was never set up, the panel says which check or tool has never reported, so the fix is a settings change rather than an investigation. The name stays on the initiative after Taiga stops trying, because that is when you are most likely to be reading it.

One stop is about the run rather than the pull request. A run that did not finish every step of its plan is never merged on its own, however green its checks. It does not reach the review gate at all: the initiative reads Build interrupted (or Build failed, when the step failed on its own code rather than on time or context) and offers Retry from failed step, the run page says which step stopped it, and the partial pull request stays open as a draft for you to read. Whether that partial work is worth merging by hand is your call.

One more is about how the checks turned green. When a check fails on the agent’s pull request, Taiga pushes commits to get it passing. If those commits also changed something that decides whether checks pass, such as a workflow file or a test configuration, then a green reached that way is not evidence the code works, and Taiga does not merge on it. It stops at once rather than waiting out the hour, names the file it stopped on, both on the initiative and in a comment on the pull request, and leaves the merge to you. Asking for another agent review does not clear this one, on purpose: looking again is not the same as you accepting the change to the checks. If the change is sound, merge by hand.

If you see none of these, nothing is blocking the merge and nothing needs your attention.

What this does not change

Merging is not shipping. Auto-merge merges a pull request into your branch and stops there. Whatever your pipeline does after a merge, it does exactly as it did before, on the same triggers. If merging to your main branch deploys, then auto-merge inherits that, which is worth knowing before you switch it on for a repository that deploys on merge.