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

ローカルの ref を使用してリモートの ref を更新し、 そして、 指定の ref を完成させるために必要なオブジェクトも送ります。

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

コマンドラインで <repository> 引数を使用してプッシュする場所が指定されてい無い場合、現在のブランチの branch.*.remote 構成を参照して、プッシュする場所を決定します。 branch.*.remote 構成が無い場合、デフォルトは origin になります。

コマンドラインで <refspec>... 引数や --all, --mirror, --tags オプションを使って何をプッシュするか指定し無かった場合、コマンドは remote.*.push 構成を参照してデフォルトの <refspec> を探し、それで見つからなかった場合は push.default 構成に準拠して何をプッシュするか決定します(push.default の意味は git-config(1) を参照ください)。

コマンドラインと構成のどちらもプッシュする対象を指定しない場合、デフォルトの振る舞いが使用されます。それは、 push.default の simple 値に対応します。 現在のブランチは対応する上流ブランチにプッシュされますが、安全対策として、上流ブランチがローカルブランチと同じ名前でない場合はプッシュが中断(abort)されます。

OPTIONS

<repository>

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

<refspec>…

どの宛先refを、 どのソースオブジェクトで更新するかを指定します。 <refspec> パラメータの形式は、 オプションのプラス記号 + に続いて、 ソースオブジェクト <src> 、 : 、宛先ref <dst> の順です。

<src> は、 通常、 あなたがプッシュしたいブランチの名前ですが、 master~4 とか HEAD (gitrevisions(7) 参照)などの任意の「SHA-1表現」にすることもできます。

<dst>は、このプッシュでリモート側のどのrefが更新されるかを指定します。 ここでは任意の式は使用できず、 実際の ref 名を指定する必要があります。 git push [<repository>] に <refspec> 引数を指定せず、 remote.<repository>.push 構成変数で <src> を指定して宛先 ref を更新する場合、 :<dst> の部分を省略することができるようになりました(このようなプッシュは、コマンドラインで <refspec> を指定しなくても、 <src> が通常更新する ref を更新することになります)。 それ以外の場合、 :<dst> がないということは、<src> と同一の ref を更新することを意味します。

<dst> が refs/(例: refs/heads/master)で始まらない場合、プッシュされる <src> の種類と、 <dst> が曖昧なのかどうかを元に、 それが 宛先 <repository> の refs/* 内のどこに属するか推測しようと試みます。

  • <dst> が <repository> リモートのrefを明確に参照している場合は、そのrefにプッシュします。

  • <src>が refs/heads/ または refs/tags/ で始まるrefに解決される場合は、その解決されたrefを <dst> の前に追加します。

  • 将来、他のあいまいさの解決策が追加される可能性がありますが、今のところ、他の場合では、試行した内容を示すエラー出力し、そして advice.pushUnqualifiedRefname 構成に応じて、あなたがプッシュしたい refs/ 名前空間を提案します。

<src>によって参照されるオブジェクトは、リモート側の<dst>参照を更新するために使用されます。 これが許可されるかどうかは、以下で詳細に説明するように、 refs/* のどこに<dst>参照が存在するかによって異なります。 以下のこれらのセクションでは、「更新」(update)とは、削除以外の変更を意味します。

refs/heads/* 名前空間はcommitオブジェクトのみを受け入れ、早送り(fast-forward)できる場合にのみ更新します。

refs/tags/* 名前空間はあらゆる種類のオブジェクト(コミットやツリーやブロブにタグ付け可能)を受け入れますが、 それらへの更新は全て拒否(reject)されます。

refs/{tags,heads}/* 以外の名前空間に任意のタイプのオブジェクトをプッシュすることができます。 タグとコミットの場合、更新が許可されるかどうかの判断においては、これらは refs/heads/* 内のコミットであるかのように扱われます。

つまり、 refs/{tags,heads}/* 以外のコミットやタグの早送り(fast-forward)が許可されています。 これは、 早送りされるものがコミットではなく、 既存のタグが指すコミットを置き換える新しいコミット(そのコミットが最後のタグまたはコミットの早送りである場合)を指すタグ・オブジェクトである場合でも可能です。 また、タグを完全に別のタグに置き換えることも、 同一コミットを指している限り許可されます。 さらに、 剥かれたタグ(peeled tag)のプッシュ(既存のタグ・オブジェクトが指すコミットをプッシュする、 または既存のコミットが指す新しいタグ・オブジェクトをプッシュ)も許可されています。

refs/{tags,heads}/* の外側にあるツリーオブジェクトとブロブオブジェクトは、 refs/tags/* の内側にある場合と同一の扱いであり、更新は拒否されます。

更新が許可されていないものに関する上記のすべてのルールは、オプションの先頭の + をrefspecに追加する(または --force コマンドラインオプションを使用する)ことでオーバーライドできます。 これに対する唯一の例外は、 refs/heads/* 名前空間が非コミットオブジェクトを受け入れるように強制することはないということです。 フックと構成は、これらのルールをオーバーライドまたは修正することもできます。たとえば、 git-config(1) の receive.denyNonFastForwards と、 githooks(5) の pre-receive や update を参照してください。

空の <src> をプッシュすると、 リモート・リポジトリーから <dst> ref を削除できます。 削除は refspec の先頭に + (または --force)がなくても常に受け入れられます。 ただし、設定やフックによって禁止されている場合は例外です。 詳細は git-config(1) の receive.denyDeletes と、 githooks(5) の pre-receive や update を参照してください。

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

tag <tag> は、 refs/tags/<tag>:refs/tags/<tag> と同じ意味です。

--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 を参照してください。

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

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

--[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 のディレクトリに当該プログラムが無いときに便利です。

--[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

通常、コマンドは、上書きに使用されたローカルrefの祖先ではないリモートrefの更新を拒否します。 また、 --force-with-lease オプションを使用すると、コマンドは、現在(current)値が期待(expect)値と一致しないリモートrefの更新を拒否します。

このフラグはこれらのチェックを無効にし、リモートリポジトリがコミットを失う原因となる可能性があります。 注意して使用してください。

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

--[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 を参照してください。

--[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" として扱われます。

--[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>

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については、失敗の理由が説明されています。

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