SYNOPSIS

'git push' [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
           [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
           [-u | --set-upstream] [-o <string> | --push-option=<string>]
           [--[no-]signed|--signed=(true|false|if-asked)]
           [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
           [--no-verify] [<repository> [<refspec>...]]

DESCRIPTION

Updates one or more branches, tags, or other references in a remote repository from your local repository, and sends all necessary data that isn’t already on the remote.

The simplest way to push is git push <remote> <branch>. git push origin main will push the local main branch to the main branch on the remote named origin.

The <repository> argument defaults to the upstream for the current branch, or origin if there’s no configured upstream.

To decide which branches, tags, or other refs to push, Git uses (in order of precedence):

  1. The <refspec> argument(s) (for example main in git push origin main) or the --all, --mirror, or --tags options

  2. The remote.*.push configuration for the repository being pushed to

  3. The push.default configuration. The default is push.default=simple, which will push to a branch with the same name as the current branch. See the CONFIGURATION section below for more on push.default.

git push may fail if you haven’t set an upstream for the current branch, depending on what push.default is set to. See the UPSTREAM BRANCHES section below for more on how to set and use upstreams.

リポジトリに「フック」を設定することで、あなたがリポジトリにプッシュするたびに興味深いことが起こります。 git-receive-pack(1) のドキュメントを参照してください。

OPTIONS

<repository>

プッシュ操作の宛先となる「リモートリポジトリ」(The \"remote\" repository)です。 このパラメーターは、URL(下記 GIT URLS セクション参照)、 または、リモートの名前(下記REMOTES セクション 参照)のどちらかです。

<refspec>…

Specify what destination ref to update with what source object.

The format for a refspec is [+]<src>[:<dst>], for example main, main:other, or HEAD^:refs/heads/main.

The <src> is often the name of the local branch to push, but it can be any arbitrary "SHA-1 expression" (see gitrevisions(7)).

The <dst> determines what ref to update on the remote side. It must be the name of a branch, tag, or other ref, not an arbitrary expression.

The + is optional and does the same thing as --force.

You can write a refspec using the fully expanded form (for example refs/heads/main:refs/heads/main) which specifies the exact source and destination, or with a shorter form (for example main or main:other). Here are the rules for how refspecs are expanded, as well as various other special refspec forms:

  • <src> without a :<dst> means to update the same ref as the <src>, unless the remote.<repository>.push configuration specifies a different <dst>. For example, if main is a branch, then the refspec main expands to main:refs/heads/main.

  • If <dst> unambiguously refers to a ref on the <repository> remote, then expand it to that ref. For example, if v1.0 is a tag on the remote, then HEAD:v1.0 expands to HEAD:refs/tags/v1.0.

  • If <src> resolves to a ref starting with refs/heads/ or refs/tags/, then prepend that to <dst>. For example, if main is a branch, then main:other expands to main:refs/heads/other

  • 特別なrefspec : (または非早送り更新を許可する場合は +:)は、Gitに、「一致する」ブランチをプッシュするように指示します。 ローカル側に存在するすべてのブランチについて、リモート側同じ名前のブランチが既に存在する場合、 リモート側が更新されます。

  • <src> may contain a * to indicate a simple pattern match. This works like a glob that matches any ref matching the pattern. There must be only one * in both the <src> and <dst>. It will map refs to the destination by replacing the * with the contents matched from the source. For example, refs/heads/*:refs/heads/* will push all branches.

  • A refspec starting with ^ is a negative refspec. This specifies refs to exclude. A ref will be considered to match if it matches at least one positive refspec, and does not match any negative refspec. Negative refspecs can be pattern refspecs. They must only contain a <src>. Fully spelled out hex object names are also not supported. For example, git push origin 'refs/heads/*' '^refs/heads/dev-*' will push all branches except for those starting with dev-

  • If <src> is empty, it deletes the <dst> ref from the remote repository. For example, git push origin :dev will delete the dev branch.

  • tag <tag> expands to refs/tags/<tag>:refs/tags/<tag>. This is technically a special syntax for git push and not a refspec, since in git push origin tag v1.0 the arguments tag and v1.0 are separate.

  • If the refspec can’t be expanded unambiguously, error out with an error indicating what was tried, and depending on the advice.pushUnqualifiedRefname configuration (see git-config(1)) suggest what refs/ namespace you may have wanted to push to.

Not all updates are allowed: see PUSH RULES below for the details.

--all
--branches

すべてのブランチ(つまり、 refs/heads/ の下のrefs)をプッシュします。 他の<refspec>と一緒に使用することはできません。

--prune

ローカルに対応するものがないリモートブランチを削除します。 たとえば、同じ名前のローカルブランチがもう存在しない場合、リモートブランチ tmp は削除されます。 これは refspecs も尊重し、 git push --prune remote refs/heads/*:refs/tmp/* は、リモートの refs/tmp/foo が refs/heads/foo が存在しない場合に削除されることを確認するものです。

--mirror

プッシュする各refに名前を付ける代わりに、 refs/ の下のすべての参照(refs/heads/ と refs/remotes/ と refs/tags/ を含むがこれらに限定されない)がリモート・リポジトリーへミラーリングされるように指定します。 新しく作成されたローカルrefはリモート側へプッシュされ、 ローカルで更新されたrefはリモート側で強制的に更新され、 削除されたrefはリモート側から削除されます。 これは、構成オプション remote.<remote>.mirror が設定されている場合のデフォルトです。

-n
--dry-run

実際に更新を送信する以外はすべて行います。

--porcelain

機械可読出力を生成します。 各refの出力ステータス行はタブで区切られ、stderrではなくstdoutに送信されます。 refの完全な記号名が表示されます。

-d
--delete

リストされているすべてのrefがリモート・リポジトリーから削除されます。 これは、すべてのrefの前にコロン(:)を付けるのと同一です。

--tags

コマンドラインに明示的にリストされているrefspecsに加えて、 refs/tags の下にあるすべてのrefがプッシュされます。

--follow-tags

このオプションがなければプッシュされるであろうすべてのrefをプッシュし、さらに refs/tags にある、リモートからは見つからないがプッシュされるrefから到達可能なコミットっぽい何かを指す注釈付きタグをプッシュします。 これは、設定変数 push.followTags で指定することもできます。 詳しくは git-config(1) にある push.followTags を参照してください。

--signed
--no-signed
--signed=(true|false|if-asked)

プッシュ要求をGPG署名して、受信側のrefを更新し、フックでチェックしたり、ログに記録したりできるようにします。 false または --no-signed の場合、署名は試行されません。 true または --signed の場合、サーバーが署名付きプッシュをサポートしていないと、プッシュは失敗します。 if-asked に設定されている場合、サーバーが署名されたプッシュをサポートしている場合にのみ署名します。 gpg --sign の実際の呼び出しが失敗した場合も、プッシュは失敗します。 受信側の詳細については、 git-receive-pack(1) を参照してください。

--atomic
--no-atomic

可能な場合は、リモート側でアトミック取引(atomic transaction)を使用します。 すべてのrefが更新されるか、エラーが発生した場合、refは更新されません。 サーバーがアトミックプッシュをサポートしていない場合、プッシュは失敗します。

-o <option>
--push-option=<option>

指定の文字列をサーバーに送信します。サーバーは、それらを受信前(pre-receive)フックと受信後(post-receive)フックに渡します。 指定の文字列には、NUL文字またはLF文字を含めることはできません。 複数の --push-option=<option> が指定されている場合、それらはすべてコマンドラインにリストされている順序で相手側に送信されます。 コマンドラインで --push-option=<option> が指定されていない場合は、代わりに構成変数 push.pushOption の値が使用されます。

--receive-pack=<git-receive-pack>
--exec=<git-receive-pack>

リモート側の git-receive-pack プログラムへのパス(path)。 sshを介してリモート・リポジトリーにプッシュするときや、デフォルトの $PATH のディレクトリに当該プログラムが無いときに便利です。

--force-with-lease
--no-force-with-lease
--force-with-lease=<refname>
--force-with-lease=<refname>:<expect>

通常、「git push」は、上書きに使用されたローカルrefの祖先ではないリモートrefの更新を拒絶(refuse)します。

リモートrefの現在の値(current value)が期待の値(expected value)である場合、このオプションはこの制限をオーバーライドします。 それ以外の場合、「git push」は失敗します。

あなたが、すでに公開しているものをリベースする必要があると想像してください。 最初に公開した履歴をリベースされた履歴に置き換えるには、「早送りしなければならない」ルールをバイパスする必要があります。 あなたのリベース作業中に他の誰かがあなたの元の履歴の上に構築した場合、リモートのブランチの先端は彼らのコミットで前進するかもしれません、そして、あなたが --force を伴って盲目的にプッシュすると彼らの作業内容は失われてしまいます。

このオプションを使用すると、 更新しようとしている履歴がリベースしたものであり、あなたがそれの置き換えを期待(expect)しているのだと指定できます。 リモートrefがまだあなたが指定したコミットを指している場合は、他の誰もrefに対して何もしていないと確信できます。 これは、 ref を明示的にロックせずに「リース」(lease;賃借権期間)を取得するようなものであり、リモートrefは「リース」がまだ有効な場合にのみ更新されます。

--force-with-lease 単独では、詳細を指定しないため、現在の値がリモート追跡ブランチと同じである必要があり、更新されるすべてのリモートrefを保護します。

--force-with-lease=<refname> では、期待する値(expected value)を指定しないので、名前付きrefを(単独で)保護します。更新される場合は、現在の値をリモート追跡ブランチと同じにする必要があります。

--force-with-lease=<refname>:<expect> は、現在の値が指定の値 <expect> と同じである必要があることで、指定のref(単独)を保護します(これは、refnameに対して持っているリモート追跡ブランチとは異なることが許可されています。または、この形式を使用する場合は、そのようなリモート追跡ブランチを持つ必要はありません)。 <expect> が空の文字列である場合、指定のrefはまだ存在していてはなりません。

注意: refの期待される現在の値を明示的に指定する --force-with-lease=<refname>:<expect> 以外のすべての形式はまだ実験的であり、この機能の経験を積むにつれてセマンティクスが変わる可能性があることに注意してください。

--no-force-with-lease は、コマンドラインでそれ以前に指定した全ての --force-with-lease をキャンセルします。

安全性に関する一般的な注意: このオプションを期待値(expected value)なしに指定すると、たとえば cronjob でリポジトリの git fetch origin のように、プッシュ先のリモートで暗黙的に git fetch を実行するものと非常に悪い相互作用が発生します。

--force に対して提供される保護は、作業の基になっていない後続の変更が破壊されないようにすることですが、バックグラウンドプロセスがバックグラウンドでrefを更新している場合、これは簡単に無効になります。 私達は、あなたには既に分かっているはずの参照をやっつけるヒューリスティックとして使用することができるリモートトラッキング情報以外何も持っていません。

あなたのエディターまたは他のシステムがバックグラウンドで git fetch を実行している場合、これを軽減する方法は、単に別のリモートをセットアップすることです:

git remote add origin-push $(git config remote.origin.url)
git fetch origin-push

これで、バックグラウンドプロセスが git fetch origin を実行するときは、 origin-push の参照は更新されないため、以下のようにコマンドを実行します:

git push --force-with-lease origin-push

これは、あなたが手動で git fetch origin-push を実行しない限り、失敗するでしょう。 もちろん、この方法は git fetch --all の実行によって完全に破綻します。この場合、あなたはそれを無効にするか、以下のようになもっと退屈なことをする必要があります:

git fetch              # update 'master' from remote
git tag base master    # mark our base point
git rebase -i master   # rewrite some commits
git push --force-with-lease=master:base master:master

つまり、上流のコードを見て、上書きしても良いと思ったバージョンの base タグを作成し、履歴を書き換え、最後にリモートバージョンがまだ base にあれば、ローカルの remotes/origin/master がバックグラウンドで何を更新したかに関わらず、変更を master に強制的にプッシュします。

あるいは、 --force-with-lease[=<refname>] と共に補助オプションとして --force-if-includes を指定すると(つまり、リモート側の ref が正確にどのコミットを指す必要があるか、あるいはリモート側のどの ref を保護しているのかを明示せずに)、 プッシュ時に、バックグラウンドで暗黙的に更新されていたかもしれないリモート追跡 ref からの更新がローカルで統合されているかを、強制更新ができる前に確認することができるようになります。

-f
--force

Usually, git push will refuse to update a branch that is not an ancestor of the commit being pushed.

This flag disables that check, the other safety checks in PUSH RULES below, and the checks in --force-with-lease. It can cause the remote repository to lose commits; use it with care.

注意: --force は、プッシュされるすべてのrefに適用されることに注意してください。 したがって、 push.default を matching に設定したり、 remote.*.push で構成された複数のプッシュ先で使用すると、現在のブランチ以外のref(リモートの対応物の背後にあるローカル参照を含む)が上書きされる可能性があります。 1つのブランチのみにプッシュを強制するには、 refspecの前に + を使用してプッシュします(例: git push origin +master を使用して、 master ブランチにプッシュを強制します)。 詳細については、上記「<refspec>…」セクションを参照してください。

--force-if-includes
--no-force-if-includes

リモート追跡refの先端がローカルに統合されている場合にのみ、更新を強制します。

このオプションを使用すると、リモートトラッキング参照の先端が、書き換えのためにそれに基づいているローカルブランチの「ref log」エントリの1つから到達可能かどうかを確認(verify)するチェックが有効になります。 このチェックでは、リモートからの更新がローカルに取り込まれていない場合、強制更新を拒否することで、更新がローカルに取り込まれていることを確認します。

オプションが --force-with-lease を指定せずに渡された場合、または --force-with-lease=<refname>:<expect> と一緒に指定された場合、それは「何もしません」(no-op)。

--no-force-if-includes を指定すると、この振る舞いが無効になります。

--repo=<repository>

このオプションは、<repository> 引数と同等です。 両方を指定すると、このオプションではなくコマンドライン引数が優先されます。

-u
--set-upstream

最新の、または正常にプッシュされたすべてのブランチについて、引数のない git-pull(1) および その他のコマンドで使用される上流(追跡)参照を追加します。 詳細については git-config(1) の branch.<name>.merge を参照してください。

--thin
--no-thin

これらのオプションは git-send-pack(1) に渡されます。 送信側と受信側が同一オブジェクトを多く共有している場合、thin転送は送信データの量を大幅に削減します。 デフォルトは --thin です。

-q
--quiet

エラーが発生しない限り、更新されたrefのリストを含むすべての出力を抑制します。 進行状況を標準エラーストリームに報告しません。

-v
--verbose

おしゃべりな実行を行います。

--progress

-q が指定されていない限り、進行状況は、端末に接続されている場合、デフォルトで標準エラーストリームに報告されます。 このフラグは、標準エラーストリームが端末に送信されていない場合でも、進行状況を強制します。

--no-recurse-submodules
--recurse-submodules=check|on-demand|only|no

このオプションは、 (プッシュする)リビジョンによって使用される、 すべてのサブモジュールのコミットが、 リモート追跡ブランチで使用可能であることを確認するために使用されます。 check を使用した場合、 Gitは、 プッシュされるリビジョンで変更されたすべてのサブモジュールのコミットが、 サブモジュールの少なくとも 1 つのリモートで使用可能であることを検証(verify)します。 コミットが欠落している場合、 プッシュは中止され、 ゼロ以外のステータスで終了(exit)します。 on-demand を使用した場合、 プッシュされるリビジョンで変更されたすべてのサブモジュールがプッシュされます。 on-demand で、 必要なすべてのリビジョンをプッシュできなかった場合も中止(abort)され、 ゼロ以外のステータスで終了(exit)します。 only を使用した場合、 すべてのサブモジュールはプッシュされますが、 スーパー・プロジェクトはプッシュされないままになります。 サブモジュールの再帰が必要ない場合は、 値 no または --no-recurse-submodules を使用して、 push.recurseSubmodules 構成変数をオーバーライドできます。

on-demand または only を使用する場合にサブモジュールに push.recurseSubmodules={on-demand,only} または `submodule.recurse ` 構成がある場合、さらに再帰が発生します。この場合、 "only" が "on-demand" として扱われます。

--verify
--no-verify

pre-push フックをON/OFFします(githooks(5) 参照)。 デフォルトは --verify で、 pre-push フックがプッシュを妨げる機会を与えます。 --no-verify を使用すると、フックは完全にバイパスされます。

-4
--ipv4

IPv6アドレスを無視して、IPv4アドレスのみを使用します。

-6
--ipv6

IPv4アドレスを無視して、IPv6アドレスのみを使用します。

GIT URLS

一般に URLには、トランスポート・プロトコルや、リモート・サーバーのアドレスや、 リポジトリーへのパスに関する情報が含まれています。トランスポート・プロトコルによっては、一部の情報が欠落している場合があります。

Gitは、 ssh プロトコルと git プロトコルと http プロトコルと https プロトコルをサポートします(さらに ftp と ftps を fetch に使用できますが、 これらは非効率的で非推奨です。 使用しないでください)。

ネイティブ・トランスポート(つまり、 git:// URL)は認証を行わないため、セキュリティで保護されていないネットワークでは注意して使用する必要があります。

以下の構文を使用できます:

  • ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>

  • git://<host>[:<port>]/<path-to-git-repo>

  • http[s]://<host>[:<port>]/<path-to-git-repo>

  • ftp[s]://<host>[:<port>]/<path-to-git-repo>

代替scp風の構文を、 sshプロトコルで使用することもできます:

  • [<user>@]<host>:/<path-to-git-repo>

この構文は、最初のコロン(:)の前にスラッシュがない場合にのみ認識されます。これは、コロンを含むローカル・パスを区別するのに役立ちます。たとえば、ローカル・パス foo:bar を、絶対パスまたは ./foo:bar として指定して、 ssh url として誤って解釈されないようにすることができます。

sshおよびgitプロトコルは、さらに ~<username> 拡張をサポートします:

  • ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>

  • git://<host>[:<port>]/~<user>/<path-to-git-repo>

  • [<user>@]<host>:~<user>/<path-to-git-repo>

ローカル・リポジトリーは、 Git によってネイティブにサポートされているため、 以下の構文を使用できます:

  • /path/to/repo.git/

  • file:///path/to/repo.git/

これら2つの構文はほとんど同等ですが、 clone 時には前者が --local オプションを意味します。 詳細は git-clone(1) を参照してください。

git clone と git fetch と git pull は、 git push と違って適切なバンドルファイルを受け入れます。 git-bundle(1) を参照してください。

Gitが特定のトランスポート・プロトコルを処理する方法を知らない場合、Gitは remote-<transport> リモート・ヘルパー(存在する場合)を使用しようとします。リモート・ヘルパーを明示的に要求するには、以下の構文を使用できます:

  • <transport>::<address>

ここで、 <address> は、パス、またはサーバーとパス、または呼び出されている特定のリモート・ヘルパーによって認識される任意のURLのような文字列です。詳細については、 gitremote-helpers(7) を参照してください。

同じ名前のリモートリポジトリが多数あり、それらに異なる形式を使用する場合(あなたの使用するURLが機能するURLに書き換えられるように)、以下の形式の構成セクションを作成できます:

        [url "<actual-url-base>"]
                insteadOf = <other-url-base>

例えば、以下のようになります:

        [url "git://git.host.xz/"]
                insteadOf = host.xz:/path/to/
                insteadOf = work:

work:repo.git や host.xz:/path/to/repo.git のようなURLは、任意のコンテキストで、 git://git.host.xz/repo.git に書き換えられます。

プッシュ専用のURLを書き換えたい場合は、以下の形式の構成セクションを作成できます:

        [url "<actual-url-base>"]
                pushInsteadOf = <other-url-base>

例えば、以下のようになります:

        [url "ssh://example.org/"]
                pushInsteadOf = git://example.org/

git://example.org/path/to/repo.git のようなURLは、プッシュの場合は ssh://example.org/path/to/repo.git に書き換えられますが、プルは引き続き元のURLのままです。

REMOTES

<repository> 引数として、URLの代わりに以下のいずれかの名前を使用できます:

  • Git構成ファイル(configuration file)内のリモート(remote)として、 $GIT_DIR/config または

  • $GIT_DIR/remotes ディレクトリ内のファイル または

  • $GIT_DIR/branches ディレクトリ内のファイル

これらはすべて、gitがデフォルトで使用するrefspecをそれぞれ含んでいるため、コマンドラインからrefspecを省略できます。

Named remote in configuration file

あなたは、 git-remote(1) を使うか、または git-config(1) を使うか、または $GIT_DIR/config ファイルを手動で編集して、これ以前に構成したリモートの名前から選択できます。このリモートのURLは、リポジトリーへのアクセスに使用されます。コマンドラインでrefspecを指定しない場合、このリモートのrefspecがデフォルトで使用されます。構成ファイルのエントリは以下のようになります:

        [remote "<name>"]
                url = <URL>
                pushurl = <pushurl>
                push = <refspec>
                fetch = <refspec>

<pushurl> は push でのみ使用されます。 これはオプションであり、 デフォルトは <URL> です。 リモートへの push は、 定義済の全ての pushurls に影響し、 pushurls が定義されていない場合は全ての定義済の URL に影響します。ただし、 複数の url が定義されている場合、 fetch 用は最初に定義された url のみです。

Named file in $GIT_DIR/remotes

あなたは、 $GIT_DIR/remotes でファイル名を指定できます。このファイルのURLは、リポジトリーへのアクセスに使用されます。コマンドラインでrefspecを指定しない場合、このファイルのrefspecがデフォルトとして使用されます。このファイルの形式は以下のとおりです:

        URL: one of the above URL formats
        Push: <refspec>
        Pull: <refspec>

Push: 行は git push で使用され、 Pull: 行は git pull と git fetch で使用されます。追加のブランチマッピングのために、複数の Push: および Pull: 行を指定できます。

Named file in $GIT_DIR/branches

$GIT_DIR/branches でファイル名を指定できます。このファイルのURLは、リポジトリーへのアクセスに使用されます。 このファイルの形式は以下のとおりです:

        <URL>#<head>

<URL> は必須です。 #<head> はオプションです。

コマンドラインで指定しない場合、操作に応じて、gitは以下のrefspecのいずれかを使用します。 <branch> は $GIT_DIR/branchs 内のこのファイルの名前であり、 <head> はデフォルトで master になります。

git fetch は以下を使用します:

        refs/heads/<head>:refs/heads/<branch>

git push は以下を使用します:

        HEAD:refs/heads/<head>

UPSTREAM BRANCHES

Git のブランチには、 オプションで上流(upstream)のリモート・ブランチを含めることができます。 Git はデフォルトでは、 リモート操作に上流ブランチを使用します。 以下に例を示します:

  • これは、 引数なしの git pull や git fetch のデフォルトです。

  • これは、引数なしの git push のデフォルトです。 たとえば、 branch.<name>.pushRemote 設定を使うことで、 pull 元とは異なるリモートに push することができ、 また、 デフォルトの push.default=simple の場合には、 設定する上流ブランチの名前は必ずローカル・ブランチのいずれかと同一の名前でなければなりません。

  • git checkout や git status など、 さまざまなコマンドは、 あなたがそのブランチをフォークして以降、 現在いるブランチと上流でそれぞれ何コミット追加されたかを教えてくれます。 たとえば、「あなたのブランチと origin/main は分岐しており、 それぞれ 2 個と 3 個の異なるコミットがあります。」("Your branch and origin/main have diverged, and have 2 and 3 different commits each respectively"). と表示されます。

上流(upstream)は .git/config の「remote」フィールドと「merge」フィールドに保存されます。 たとえば、 main の上流が origin/main の場合以下のようになります:

[branch "main"]
   remote = origin
   merge = refs/heads/main

あなたは git Push --set-upstream <remote> <branch> を使用して上流ブランチを明示的に設定できますが、 多くの場合、 Git は自動的に上流を設定します。 以下に例を示します:

  • あなたがリポジトリーのクローンを作成すると、 Git はデフォルト・ブランチの上流を自動的に設定します。

  • あなたが push.autoSetupRemote 設定オプションを設定している場合、 初めてブランチをプッシュするときに、 git Push が自動的に上流を設定します。

  • git checkout <branch> を使用してリモート追跡ブランチをチェックアウトすると、 その名前でローカル・ブランチが自動的に作成され、 上流が上流ブランチに設定されます。

Note
 上流ブランチは、「ブランチの追跡情報を設定する」(set the branch’s tracking information)と言うように、 「追跡情報」(tracking information)と呼ばれることもあります。

OUTPUT

git push の出力は、使用する転送方法によって異なります。 このセクションでは、Gitプロトコルで(ローカルまたはssh経由で)プッシュするときの出力について説明します。

プッシュのステータスは表形式で出力され、各行は単一のrefのステータスを表します。 各行の形式は以下のとおりです:

 <flag> <summary> <from> -> <to> (<reason>)

--porcelain が使用されている場合、出力の各行は以下の形式になります:

 <flag> \t <from>:<to> \t <summary> (<reason>)

最新のrefのステータスは、 --porcelain または --verbose オプションが使用されている場合にのみ表示されます。

flag

refのステータスを示す単一の文字:

(space)

早送り(fast-forward)プッシュに成功した

+

強制更新に成功した

-

refの削除に成功した

*

新しいrefのプッシュに成功した

!

プッシュが拒否された、またはプッシュに失敗したref

=

すでに最新でプッシュする必要がなかったref

summary

正常にプッシュされたrefの場合、概要には、refの古い値と新しい値が git log の引数として使用するのに適した形式で表示されます(ほとんどの場合は <old>..<new> で、強制的な非早送り更新の場合は <old>...<new> です)。

失敗した更新については、以下の詳細が示されます:

rejected

Gitはrefをまったく送信しようと試みませんでした。これは通常、それが早送り(fast-forward)では無く、かつ、あなたが更新を強制しなかったためです。

remote rejected

リモート側が更新を拒否しました。 これは通常、リモート側のフックが原因で発生するか、リモート・リポジトリーで次の安全オプションのいずれかが有効になっていることが原因です: receive.denyCurrentBranch (チェックアウトされたブランチへのプッシュ用) または receive.denyNonFastForwards (強制的な非早送り更新用) または receive.denyDeletes または receive.denyDeleteCurrent です。 git-config(1) を参照してください。

remote failure

リモート側が ref の更新成功を報告しませんでした。 おそらく、 リモート側の一時的なエラー、 またはネットワーク接続の切断、 またはその他の過渡的なエラーが原因です。

from

プッシュされるローカルrefの名前から、その refs/<type>/ プレフィックスを取り除いたもの。 削除の場合、ローカルrefの名前は省略されます。

to

更新されるリモートrefの名前から、 refs/<type>/ プレフィックスを取り除いたもの。

reason

人間が読める説明。 正常にプッシュされたrefの場合、説明は必要ありません。 失敗したrefについては、失敗の理由が説明されています。

PUSH RULES

As a safety feature, the git push command only allows certain kinds of updates to prevent you from accidentally losing data on the remote.

Because branches and tags are intended to be used differently, the safety rules for pushing to a branch are different from the rules for pushing to a tag. In the following rules "update" means any modifications except deletions and creations. Deletions and creations are always allowed, except when forbidden by configuration or hooks.

  1. If the push destination is a branch (refs/heads/*): only fast-forward updates are allowed, which means the destination must be an ancestor of the source commit. The source must be a commit.

  2. If the push destination is a tag (refs/tags/*): all updates will be rejected. The source can be any object.

  3. If the push destination is not a branch or tag:

    • If the source is a tree or blob object, any updates will be rejected

    • If the source is a tag or commit object, any fast-forward update is allowed, even in cases where what’s being fast-forwarded is not a commit, but a tag object which happens to point to a new commit which is a fast-forward of the commit the last tag (or commit) it’s replacing. Replacing a tag with an entirely different tag is also allowed, if it points to the same commit, as well as pushing a peeled tag, i.e. pushing the commit that existing tag object points to, or a new tag object which an existing commit points to.

You can override these rules by passing --force or by adding the optional leading + to a refspec. The only exceptions are that no amount of forcing will make a branch accept a non-commit object, and forcing won’t make the remote repository accept a push that it’s configured to deny.

Hooks and configuration can also override or amend these rules, see e.g. receive.denyNonFastForwards and receive.denyDeletes in git-config(1) and pre-receive and update in githooks(5).

NOTE ABOUT FAST-FORWARDS

コミットAを指していたとあるブランチ(またはより一般的には ref)が、 別のコミットBを指すように変更された場合、 BがAの子孫である場合に限り、 早送り(fast-forward)更新と呼ばれます。

AからBへの早送り(fast-forward)更新では、元のコミットA上に構築されたコミットのセットは、新しいコミットB上に構築されたコミットのサブセットです。 したがって、履歴が失われることはありません。

対照的に、非早送り更新は履歴を失います。 たとえば、あなたと他の誰かが同じコミットXで開始し、あなたがコミットBにつながる履歴を作成し、他の人がコミットAにつながる履歴を作成したとします。そうすると履歴は以下のようになります:

      B
     /
 ---X---A

さらに、もう一人が既に A につながる変更を元のリポジトリにプッシュしており、そこからあなたたち二人が元のコミット X を取得したとします。

他の人が行ったプッシュにより、コミットXをポイントしていたブランチがコミットAをポイントするように更新されました。これは早送りです。

しかし、あなたがプッシュしようとすると、コミットBでブランチ(現在はAを指している)を更新しようとします。これは早送りにはなりません。 そうすると、コミットAによって導入された変更は失われます。なぜなら、全員がB上に構築を開始するためです。

このコマンドは、デフォルトでは、このような履歴の損失を防ぐための早送り(fast-forward)ではない更新を許可していません。

自分の作業(XからBへの履歴)または他の人の作業(XからAへの履歴)を失いたくない場合は、最初にリポジトリから履歴をフェッチし、行われた変更を含む履歴を作成する必要があり、両方の当事者によって行われた変更を含む履歴を作成し、結果をプッシュバックします。

あなたは git pull を実行し、潜在的な競合を解決して、結果を git push することができます。 git pull は、コミットAとBの間にマージコミットCを作成します。

      B---C
     /   /
 ---X---A

結果のマージコミットでAを更新すると、早送り(fast-forward)され、そして、プッシュが受け入れられます。

または、あなたは git pull --rebase を使用して、A上のXとBの間のあなたの変更をリベースし、結果をプッシュバックすることもできます。 リベースは、A上のXとBの間の変更を構築する新しいコミットDを作成します。

      B   D
     /   /
 ---X---A

繰り返しになりますが、このコミットでAを更新すると早送り(fast-forward)され、プッシュが受け入れられます。

プッシュしようとしたときに非早送拒否(non-fast-forward rejection)が発生するもう一つの一般的な状況があります。 それは、 他の誰もプッシュしていないリポジトリーにプッシュしている場合でも発生する可能性があります。 (このセクションの最初の図のように、)あなたが自分でコミットAをプッシュした後、 git commit --amend でコミットAを置き換えてコミットBを作成し、 すでにAをプッシュしていたことを忘れてBをプッシュしようとすると、 その問題が発生します。 その問題かつ、 更に、 その間に誰も以前のコミットAを取得していない(そして、 それをもとに作業を開始していない)ことを確信している場合に限り、 git push --force を実行して上書きできます。 つまり、 git push --force は、履歴を意図的に失うこと場合にのみ使用される方法です。

EXAMPLES

git push

git push <remote> のように機能します。ここで、<remote>は現在のブランチのリモート(または、現在のブランチにリモートが構成されていない場合は origin)です。

git push origin

追加の構成がない場合、現在のブランチが、構成された上流の現在のブランチと同一の名前の場合は、現在のブランチを構成された上流(branch.<name>.merge 構成値)にプッシュし、それ以外の場合はプッシュせずにエラーになります。

<refspec>が指定されていない場合のこのコマンドのデフォルトの動作は、リモートの push オプション、または push.default 構成変数を設定することで構成できます。

たとえば、デフォルトで現在のブランチのみを origin にプッシュするには、 git config remote.origin.push HEAD を使用します。 有効な <refspec> (以下の例のような)を git push origin のデフォルトとして設定できます。

git push origin :

「マッチする」ブランチを origin にプッシュします。 「マッチする」ブランチの説明については、上記 OPTIONS セクションの <refspec> を参照してください。

git push origin master

ソースリポジトリで master に一致するrefを探し(ほとんどの場合 refs/heads/master を探し)、 origin リポジトリで同一ref(例: refs/heads/master)を更新します。 master がリモートに存在しなかった場合は作成されます。

git push origin HEAD

現在のブランチをリモートの同一の名前にプッシュする便利な方法。

git push mothership master:satellite/master dev:satellite/dev

master と一致するソースref(例: refs/heads/master)を使用して、 mothership リポジトリ内の satellite/master(おそらく refs/remotes/satellite/master)と一致するrefを更新します。 dev と satellite/dev についても同様にします。

マッチングのセマンティクスの説明については、 上記「<refspec>…」について説明しているセクションを参照してください。

これは、 mothership で実行される git fetch を、 satellite での作業を統合するために逆方向に実行される git push でエミュレートするもので、一方通行でしか接続できないときによく必要になります(つまり、 satellite はsshで mothership に入ることができますが、 satellite がファイアウォールの背後にあるか、sshdを実行していないため、 mothership は `satellite`への接続を開始できません)。

この git push を satellite のマシンで実行した後、 mothership に ssh して git merge を実行すれば、satellite で行われた変更を git pull でプルするエミュレーションが完成します。

git push origin HEAD:master

現在のブランチを、 origin リポジトリ内の master に一致するリモートrefにプッシュします。 この形式は、ローカル名を気にせずに現在のブランチをプッシュするのに便利です。

git push origin master:refs/heads/experimental

現在の master ブランチをコピーして、 origin リポジトリにブランチ experimental を作成します。 これは、ローカル名とリモート名が異なる場合に、リモートリポジトリに新しいブランチまたはタグを作成する時のみ必要な形式です。 それ以外の場合は、ref名自体で機能します。

git push origin :experimental

origin リポジトリで experimental に一致するref(たとえば refs/heads/experimental)を見つけて削除します。

git push origin +dev:master

origin リポジトリのmasterブランチをdevブランチで更新し、早送り以外の更新(non-fast-forward updates)を可能にします。「これにより、参照されていないコミットがoriginリポジトリにぶら下がる可能性があります。」 早送りが(fast-forward)不可能な以下の状況を考慮してください: 

            o---o---o---A---B  origin/master
                     \
                      X---Y---Z  dev

上記コマンドは、originリポジトリを以下のように変更します

                      A---B  (unnamed branch)
                     /
            o---o---o---X---Y---Z  master

コミットAとBは、もはやシンボリック名のブランチに属さなくなるため、到達不能になります。 そのため、これらのコミットは、originリポジトリの git gc コマンドによって削除されます。

SECURITY

フェッチ・プロトコルやプッシュ・プロトコルは、 共有することを意図していない一方の側が他方のリポジトリからデータを盗むのを防ぐようには設計されていません。悪意のある者から保護する必要のあるプライベートデータがある場合、最善のオプションはそれを別のリポジトリに保存することです。これは、クライアントとサーバーの両方に適用されます。特に、サーバー上の名前空間は、読み取りアクセス制御には効果的ではありません。リポジトリ全体への読み取りアクセスで信頼できるクライアントにのみ、名前空間への読み取りアクセスを許可する必要があります。

既知の攻撃ベクトル(attack vectors)は以下のとおりです:

  1. 被害者は have 行を送信して、 所有しているオブジェクトのIDを広告(advertise)します。 これらのIDは明示的に共有されることを意図していませんが、 相手(peer)もそれを持っている場合に転送を最適化するために使用できます。 攻撃者は盗むオブジェクトID Xを選択して、 X への ref 送信しますが、 被害者はすでにXのコンテンツを持っているため、 Xのコンテンツを送信する必要はありません。 これで、 被害者は攻撃者がXを持っていると信じ、 X のコンテンツを後で攻撃者に送り返します。 (この攻撃は、クライアントがアクセスできる名前空間に X への ref を作成してフェッチすることにより、 クライアントがサーバー上で実行するのが最も簡単です。 サーバーがクライアント上で実行する最も可能性の高い方法は、 X をパブリック・ブランチにマージし、ユーザーがこのブランチで追加の作業を行い、マージに気付かずにサーバーにプッシュバックすることを期待します。)

  2. #1 と同様に、攻撃者は盗むオブジェクトID Xを選択します。被害者は、攻撃者がすでに持っているオブジェクトYを送信し、攻撃者はYではなくXを持っていると誤って主張するため、被害者はYをXに対するデルタとして送信します。デルタは、攻撃者にYに類似したXの領域を明らかにします。

CONFIGURATION

このセクションの以下のすべては、 git-config(1) ドキュメントの抜粋です。 内容は git-config(1) ドキュメント にあるものと同一です:

push.autoSetupRemote

true に設定すると、現在のブランチの上流追跡(upstream tracking)が存在しない場合、デフォルトのpushで --set-upstream を想定します。 このオプションは、 push.default オプションの simple や upstream や current で有効になります。 (push.default=current の振る舞いのように、)デフォルトで新しいブランチをデフォルトのremoteにプッシュしたい場合に便利で、これは、あなたが上流追跡(upstream tracking)も設定したい場合にも便利です。 このオプションの恩恵を受ける可能性が最も高いワークフローは、すべてのブランチがremoteで同じ名前を持つことが期待される「単純な」中央ワークフローです。

push.default

(コマンドライン、構成、またはその他の場所で、)refspecが指定されていない場合に git push が実行するアクションを定義します。 特定の作業フローに適するさまざまな値があります。 たとえば、純粋に中央のワークフロー(つまり、フェッチ元がプッシュ先と等しい)では、 upstream がおそらく必要なものです。 可能な値は以下のとおりです:

  • nothing - refspecが指定されていない限り、何もプッシュ(エラー出力)しないでください。 これは主に、常に明示的にすることで間違いを避けたい人を対象としています。

  • current - 現在のブランチをプッシュして、受信側で同一の名前のブランチを更新します。 中央作業フローと非中央作業フローの両方で機能します。

  • upstream - 現在のブランチを、通常その変更が現在のブランチに統合されるブランチにプッシュバックします(これを @{upstream} と呼びます)。 このモードは、通常プルするのと同じリポジトリ(つまり中央ワークフロー)にプッシュする場合にのみ意味があります。

  • tracking - これは upstream の非推奨の同義語です。

  • simple - 現在のブランチをリモートの同一名のにプッシュします。

    あなたが一元化された作業フロー(あなたのプル元の同一のリポジトリにプッシュする、通常は origin )で作業している場合は、あなたは同一の名前でアップストリームブランチを構成する必要があります。

    このモードはGit2.0以降のデフォルトであり、初心者に適した最も安全なオプションです。

  • matching - 送信側受信側両方で同一の名前のすべてのブランチをプッシュします。 これにより、プッシュするリポジトリは、プッシュされるブランチのセットを記憶するようになります(たとえば、常に「maint」と「master」をプッシュし、他のブランチがない場合、プッシュするリポジトリには、これら2つのブランチがあり、ローカルの「maint」と「master」がそこにプッシュされます)。

    このモードを効果的に使用するには、 git push を実行する前に、あなたがプッシュしたい「すべてのブランチ」がプッシュされる準備ができていることを確認する必要があります。このモードの要点は、すべてのブランチを一度にプッシュできるようにすることです。通常、1つのブランチのみで作業を終了して結果をプッシュする場合、他のブランチは未完了ですので、このモードは適していません。 また、このモードは、共有中央リポジトリにプッシュするのには適していません。他の人がそこに新しいブランチを追加したり、コントロール外の既存のブランチの先端を更新したりする可能性があるためです。

    これは以前はデフォルトでしたが、Git 2.0以降ではそうではありません(simple が新しいデフォルトです)。

push.followTags

trueに設定されている場合、デフォルトで --follow-tags オプションを有効にします。 --no-follow-tags を指定することにより、プッシュ時にこの構成をオーバーライドできます。

push.gpgSign

ブール値、または文字列 if-asked に設定できます。 true値を指定すると、 --signed linkgit:git-push [1]に渡されたかのように、すべてのプッシュがGPG署名されます。 文字列 if-asked を指定し、サーバーがサポートしている場合は、 --signed=if-asked が git push に渡されたかのように、プッシュで署名されます。 誤った値は、優先度の低い構成ファイルの値を上書きする可能性があります。 明示的なコマンドラインオプションは、常にこの設定オプションを上書きします。

push.pushOption

コマンドラインから --push-option=<option> 引数が指定されていない場合、 git push はこの変数の各<value> が --push-option=<value> として指定されているかのように動作します。

これは複数値の変数であり、優先度の高い構成ファイル(リポジトリ内の .git/config など)で空の値を使用して、優先度の低い構成ファイル($HOME/.gitconfig など)から継承された値をクリアできます。

Example:

/etc/gitconfig
  push.pushoption = a
  push.pushoption = b

~/.gitconfig
  push.pushoption = c

repo/.git/config
  push.pushoption =
  push.pushoption = b

This will result in only b (a and c are cleared).
push.recurseSubmodules

値は check または on-demand または only または no のいずれかで、 push --recurse-submodules と同じ動作になります。 設定されていない場合、 submodule.recurse が設定されていない限り、 デフォルトで no が使用されます(submodule.recurse が設定されている場合、 submodule.recurse の true 値は on-demand を意味します)。

push.useForceIfIncludes

「true」に設定すると、コマンドラインで git-push(1) のオプションとして --force-if-includes を指定するのと同じです。 プッシュ時に --no-force-if-includes を追加すると、この構成設定が上書きされます。

push.negotiate

「true」に設定されている場合は、クライアントとサーバーが共通のコミットを見つけようとするネゴシエーションの段階で送信されるパックファイルのサイズを縮小してみます。 「false」の場合、Gitはサーバーのref広告のみに依存して、共通のコミットを検索します。

push.useBitmaps

false に設定すると、 pack.useBitmaps が true であっても git push のビットマップの使用が無効になり、他の git 操作でのビットマップの使用が妨げられません。 デフォルトは true です。

GIT

Part of the git(1) suite