| 1 | --- |
| 2 | title: Pull requests and checks |
| 3 | description: What the merge box shows before a pull request can merge, the checks your workflows report and which ones a merge needs, and conflicts found before anyone tries to merge. |
| 4 | --- |
| 5 | |
| 6 | At the foot of an open pull request's conversation, the **merge box** says |
| 7 | what stands between it and its target branch: its checks, its reviews, |
| 8 | whether it merges cleanly, and the button that merges it. Everything in it |
| 9 | updates by itself while something is still running. |
| 10 | |
| 11 | A pull request g1t made shows **g1t** as its author and **requested by** |
| 12 | the person who asked for it. That person can manage it as its author could, |
| 13 | and cannot approve it; see |
| 14 | [who a pull request is for](/guides/working-with-g1t/#who-a-pull-request-is-for). |
| 15 | |
| 16 | ## Checks |
| 17 | |
| 18 | A pull request's checks are the statuses reported on its head commit. Most |
| 19 | come from the repository's [workflows](/guides/actions/): every workflow |
| 20 | that runs on `pull_request` runs on every pull request's head, whoever |
| 21 | opened it, a person or an agent, and reports a check named after the |
| 22 | workflow. A workflow named `CI` reports the check `CI`; its status context |
| 23 | is `CI / pull_request`, the workflow's name and the event it ran for. Other |
| 24 | parts of g1t report under their own names, such as `g1t / deploy` (or |
| 25 | `g1t / deploy (<project>)`) for a [deployment](/guides/deployments/). |
| 26 | |
| 27 | Which checks a merge needs is up to the repository: its |
| 28 | [required status checks](#required-status-checks). The merge box lists |
| 29 | those first: |
| 30 | |
| 31 | ```text |
| 32 | Required checks: 1 of 2 passing |
| 33 | CI failing Details |
| 34 | Lint passing Details |
| 35 | ``` |
| 36 | |
| 37 | Each required check is **passing**, **failing**, **running**, or |
| 38 | **expected**, "waiting for status to be reported", when nothing has |
| 39 | reported it on the head commit yet. **Details** opens the run that |
| 40 | reported it. Below them are all the other checks, workflow runs job by job, |
| 41 | each with its state and how long it took. A check that is not required is |
| 42 | shown, but never holds a merge. |
| 43 | |
| 44 | A workflow job's **Details** opens its log on the run's page, where every |
| 45 | step's output is kept. |
| 46 | |
| 47 | ### Running them again |
| 48 | |
| 49 | People with the Write [role](/guides/access-and-roles/) or higher can press |
| 50 | **Re-run failed jobs** on a workflow run that failed, to run its failed jobs |
| 51 | again on the same commit. Every push to the pull request runs its workflows |
| 52 | again on the new head. |
| 53 | |
| 54 | ### A repository with no checks |
| 55 | |
| 56 | When a repository has no workflows, the merge box says **This repository |
| 57 | has no checks**: nothing proves a change works, for people or for agents. |
| 58 | **Add CI** writes a starter workflow for you; see |
| 59 | [add CI](/guides/actions/#add-ci). The same offer is on the |
| 60 | **Branches and merging** settings page and the **Actions** page. |
| 61 | |
| 62 | ## Required status checks |
| 63 | |
| 64 | Rules for merging belong to the default branch, since every pull request |
| 65 | merges into it. Someone with the Maintain [role](/guides/access-and-roles/) |
| 66 | or higher sets them under the repository's **Settings → Branches and |
| 67 | merging**, in **Branch protection**: |
| 68 | |
| 69 | | Setting | Default | What it does | |
| 70 | | --- | --- | --- | |
| 71 | | Require a pull request to change the default branch | Off | Refuses pushes to the default branch; changes reach it only by merging. See [protected branches](/guides/git/#protected-branches). | |
| 72 | | Required status checks | None | The checks that must pass on a pull request's head before it merges. | |
| 73 | | Required approvals | None | How many reviewers must approve before a merge, 0 to 3 on the page (up to 6 from the API). A reviewer who asked for changes blocks it. | |
| 74 | | g1t's approval counts | On | Off means approvals have to come from people. | |
| 75 | | Require branches to be up to date before merging | Off | On means a pull request behind the default branch has to catch up, and its checks run again, before it merges. | |
| 76 | | Merge through a queue | Off | See [merge queue](/guides/merge-queue/). | |
| 77 | | Allow bypassing required checks | On | Lets someone who may merge tick **bypass** when merging, to merge without the required checks passing. Off means nobody can. | |
| 78 | |
| 79 | ### Choosing the checks |
| 80 | |
| 81 | **Required status checks** offers the check names reported on the |
| 82 | repository's commits in the last 30 days, each with the events it was seen |
| 83 | for, such as `pull_request` and `merge_group`. Pick from the list, or type a |
| 84 | name that has not reported yet. A repository can require at most 20. |
| 85 | |
| 86 | A required check is met by a status of that name on the pull request's head, |
| 87 | whatever event reported it: |
| 88 | |
| 89 | | What reported it | What the merge does | |
| 90 | | --- | --- | |
| 91 | | A status that failed | Refused: "The required check CI failed." | |
| 92 | | A status still pending | Held: "The required check CI is still running." | |
| 93 | | Nothing yet | Held: "The required check CI has not reported on this commit yet." | |
| 94 | | Success | Allowed | |
| 95 | |
| 96 | The same rule holds wherever a pull request merges: the merge button, |
| 97 | [`merge_pull_request`](/reference/api/pull-requests/merge-pull-request/), |
| 98 | a g1t agent's [automatic merge](/guides/working-with-g1t/#merging-automatically) |
| 99 | and the [merge queue](/guides/merge-queue/). With **Allow bypassing required |
| 100 | checks** on, the merge button has a **bypass** box, and the API takes |
| 101 | `ignore_checks: true`. |
| 102 | |
| 103 | A check that only exists once a workflow has run, such as `CI` from a |
| 104 | workflow added in a pull request, appears in the list after that workflow |
| 105 | has run once. |
| 106 | |
| 107 | ### From the API |
| 108 | |
| 109 | ```sh |
| 110 | curl https://api.g1t.sh/repos/<workspace>/<repo>/check-names \ |
| 111 | -H "Authorization: Bearer $G1T_TOKEN" |
| 112 | ``` |
| 113 | |
| 114 | [`list_check_names`](/reference/api/repositories/list-check-names/) |
| 115 | returns the names seen in the last 30 days, most recent first, each as |
| 116 | `{name, events, last_seen}`. It needs the `repo:read` scope. |
| 117 | |
| 118 | ```sh |
| 119 | curl -X PATCH https://api.g1t.sh/repos/<workspace>/<repo>/settings \ |
| 120 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 121 | -H "Content-Type: application/json" \ |
| 122 | -d '{"required_checks": ["CI", "g1t / deploy"]}' |
| 123 | ``` |
| 124 | |
| 125 | [`update_repo_settings`](/reference/api/repositories/update-repo-settings/) |
| 126 | takes `required_checks`, which replaces the whole list, along with |
| 127 | `required_approvals`, `count_agent_approvals`, `require_up_to_date`, |
| 128 | `merge_queue` and `allow_ignoring_checks`; |
| 129 | [`get_repo_settings`](/reference/api/repositories/get-repo-settings/) |
| 130 | returns them. On the MCP server they are the `repository` tool's |
| 131 | `check_names`, `get_settings` and `update_settings` actions. |
| 132 | |
| 133 | ## Conflicts |
| 134 | |
| 135 | g1t works out whether a pull request merges cleanly into its target before |
| 136 | anyone tries to merge it, and again whenever either side moves: a push to |
| 137 | the pull request, or anything landing on the target branch. |
| 138 | |
| 139 | 1. **Without a sandbox.** g1t compares the files the pull request changed |
| 140 | since it and the target last agreed with the files the target changed |
| 141 | since then. If they share none, the merge cannot conflict, and that is |
| 142 | the answer. |
| 143 | 2. **With a short probe.** If they share files, a sandbox merges the two |
| 144 | commits without an agent and pushes nothing, and reports the files that |
| 145 | conflict. Meanwhile the box says **Checking whether this merges cleanly**, |
| 146 | and the merge button waits. Probes are metered as sandbox time; each |
| 147 | pair of commits is probed once, and a repository runs at most |
| 148 | three at a time, the rest following in turn. |
| 149 | |
| 150 | A pull request that conflicts shows **This branch has conflicts that must |
| 151 | be resolved**, the conflicting files, each linked to its diff, and three |
| 152 | ways to resolve them: |
| 153 | |
| 154 | - **Resolve with g1t.** g1t merges the target branch in, |
| 155 | resolves the conflicts keeping what both sides meant, and pushes the |
| 156 | result. It is told which files conflict. Available to whoever can push to |
| 157 | the pull request: for a pull request's fork, whoever opened it (whoever |
| 158 | asked g1t for one it made); for a branch, anyone with the Write role or |
| 159 | higher. |
| 160 | - **Resolve in the browser.** Coming soon. |
| 161 | - **On the command line.** The box lists the commands, each with a copy |
| 162 | button. For a pull request from a branch: |
| 163 | |
| 164 | ```sh |
| 165 | git fetch origin |
| 166 | git checkout my-branch |
| 167 | git merge origin/main |
| 168 | # fix each conflicting file, then |
| 169 | git add -A && git commit --no-edit |
| 170 | git push origin my-branch |
| 171 | ``` |
| 172 | |
| 173 | For a pull request in its own fork, clone the fork and pull `main` into |
| 174 | it instead: |
| 175 | |
| 176 | ```sh |
| 177 | git clone https://g1t.sh/pulls/<id>.git && cd <id> |
| 178 | git pull --no-rebase https://g1t.sh/<owner>/<repo>.git main |
| 179 | ``` |
| 180 | |
| 181 | While it conflicts, it cannot be merged or added to the |
| 182 | [merge queue](/guides/merge-queue/), and the merge button says so. Once the |
| 183 | fix is pushed, g1t works it out again. |
| 184 | |
| 185 | A pull request that only has fallen behind its target, without conflicts, |
| 186 | still merges: merging brings it up to date first, unless the repository |
| 187 | requires pull requests to be up to date. |
| 188 | |
| 189 | ## Catching up |
| 190 | |
| 191 | When the target branch has moved, the merge box says **main has moved since |
| 192 | this was made**. Whoever can push to the pull request (whoever opened it, |
| 193 | or asked g1t for it, for one in its own fork; anyone with the Write |
| 194 | [role](/guides/access-and-roles/) or higher, for a branch) can |
| 195 | press **Catch up with main now**: |
| 196 | |
| 197 | 1. **When the two changed different files**, g1t merges `main` in itself, |
| 198 | in a few seconds. The merge commit is named **Merge main into |
| 199 | *branch***, has the pull request's head and `main`'s head as its |
| 200 | parents, and is authored and pushed as you. The box then says **Brought |
| 201 | up to date with main**, and the workflows run again on the |
| 202 | new commit, as after any push. |
| 203 | 2. **When both changed some of the same files**, a sandbox merges `main` in |
| 204 | with git, and [g1t](/guides/working-with-g1t/) resolves any conflict. |
| 205 | The box says what is happening (**g1t is resolving conflicts with |
| 206 | main** when the merge is known to conflict) with the run's live step and |
| 207 | how long it has taken. It usually takes about a minute. When the result |
| 208 | is pushed, the box shows the pull request up to date; if the run fails, |
| 209 | or nothing has been pushed after five minutes, the box says so and |
| 210 | offers **Try again**. Nothing is pushed by a run that fails. |
| 211 | |
| 212 | Either way the merge is pushed only if the pull request's branch is still |
| 213 | where it was when the catch-up started. If someone pushed to it meanwhile, |
| 214 | the catch-up stops with nothing lost, and you can press it again. |
| 215 | |
| 216 | The second case needs g1t's agent enabled for the workspace and is |
| 217 | [charged](/guides/usage-and-billing/#what-is-charged) as agent work; the |
| 218 | first is not. |
| 219 | |
| 220 | A pull request [g1t](/guides/working-with-g1t/) opened that is found to conflict |
| 221 | is sent back to resolve it by itself, before it is ready. |
| 222 | |
| 223 | ## From the API |
| 224 | |
| 225 | `GET /repos/{owner}/{name}/pulls/{number}` returns, besides the pull request: |
| 226 | |
| 227 | | Field | What it is | |
| 228 | | --- | --- | |
| 229 | | `statuses` | What each workflow run, and anything else that reports statuses, said about its head, with a link to the run. | |
| 230 | | `required_checks` | Each check the default branch requires, as it stands on the head: `name`, `state` (`success`, `failure`, `pending`, or `expected` when nothing has reported it yet), `description` and `target_url`. Empty when none are required. | |
| 231 | | `checks` | The latest record against its head from g1t itself, such as the merge queue taking it out, with `earlier_checks` before it. | |
| 232 | | `mergeable` | `clean`, `conflicting`, `checking` or `unknown`. | |
| 233 | | `conflicts` | When conflicting, the files that conflict. | |
| 234 | | `behind` | Whether its target has moved on without it. | |
| 235 | |
| 236 | An agent sees the same through the `pull_request` tool's `get` action. |