---
name: "git-branchless-submit"
section: "1"
platform: "linux"
package: "git-branchless"
version: "0.11.1-2"
release: "Arch Linux 2026-11-01"
platforms: ["linux"]
url: "https://new.carta.tech/git-branchless-submit"
---

# git-branchless-submit(1)

Push commits to a remote

## NAME

submit - Push commits to a remote

## SYNOPSIS

**submit** \[**--hidden**\] \[**-F**\|**--forge**\] \[**-c**\|**--create**\] \[**-d**\|**--draft**\] \[**-m**\|**--message**\] \[**-j**\|**--jobs**\] \[**-s**\|**--strategy**\] \[**-n**\|**--dry-run**\] \[**-h**\|**--help**\] \[*REVSETS*\]

## DESCRIPTION

Push commits to a remote

## OPTIONS

- **--hidden**

  Include hidden commits in the results of evaluating revset expressions

- **-F**, **--forge** *\<FORGE\_KIND\>*

  The Git hosting provider to use, called a "forge". If not provided, an attempt will be made to automatically detect the forge used by the repository. If no forge can be detected, will fall back to the "branch" forge\

  *Possible values:*

  - •

    branch: Force-push branches to the default push remote. You can configure the default push remote with \`git config remote.pushDefault \<remote\>\`

  - •

    github: Force-push branches to the remote and create a pull request for each branch using the \`gh\` command-line tool. WARNING: likely buggy!

  - •

    phabricator: Submit code reviews to Phabricator using the \`arc\` command-line tool

- **-c**, **--create**

  If there is no associated remote commit or code review object for a given local commit, create the remote object by pushing the local commit to the forge

- **-d**, **--draft**

  If the forge supports it, create code reviews in "draft" mode

- **-m**, **--message** *\<MESSAGE\>*

  If the forge supports it, an optional message to include with the create or update operation

- **-j**, **--jobs** *\<NUM\_JOBS\>*

  If the forge supports it, how many jobs to execute in parallel. The value \`0\` indicates to use all CPUs

- **-s**, **--strategy** *\<EXECUTION\_STRATEGY\>*

  If the forge supports it and uses a tool that needs access to the working copy, what kind of execution strategy to use\

  *Possible values:*

  - •

    working-copy: Default. Run the tests in the working copy. This requires a clean working copy. This is useful if you want to reuse build artifacts in the current directory

  - •

    worktree: Run the tests in a separate worktree (managed by git-branchless). This is useful if you want to run tests in parallel, or if you want to run tests on a different commit without invalidating build artifacts in the current directory, or if you want to run tests while your working copy is dirty

- **-n**, **--dry-run**

  Don't push or create anything. Instead, report what would be pushed or created. (This may still trigger fetching information from the forge.)

- **-h**, **--help**

  Print help (see a summary with '-h')

- \[*REVSETS*\] \[default: stack()\]

  The commits to push to the forge. Unless \`--create\` is passed, this will only push commits that already have associated remote objects on the forge