日本語 ▾ トピック ▾ 最新バージョン ▾ git-push は 2.48.0 で最終更新されました

名前

git-push - 関連するオブジェクトと共にリモートの参照を更新する

概要

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>…​]]

説明

ローカルの参照を使用してリモートの参照を更新し、指定された参照を完了するために必要なオブジェクトを送信します。

リポジトリにプッシュするたびに、そこに*フック*を設定することで、興味深いことを起こすことができます。git-receive-pack[1]のドキュメントを参照してください。

コマンドラインで<repository>引数でプッシュ先を指定しない場合、現在のブランチのbranch.*.remote設定を調べてプッシュ先を決定します。この設定がない場合、デフォルトで_origin_になります。

コマンドラインで<refspec>...引数または--all、--mirror、--tagsオプションでプッシュ対象を指定しない場合、コマンドはremote.*.push設定を調べてデフォルトの<refspec>を検索し、見つからない場合はpush.default設定に従ってプッシュ対象を決定します（push.defaultの意味についてはgit-config[1]を参照してください）。

コマンドラインも設定もプッシュ対象を指定しない場合、デフォルトの動作が使用されます。これはpush.defaultのsimple値に相当します。現在のブランチは対応する上流ブランチにプッシュされますが、安全対策として、上流ブランチの名前がローカルブランチと同じでない場合、プッシュは中止されます。

オプション

<repository>

プッシュ操作の宛先となる「リモート」リポジトリです。このパラメータは、URL（以下のGIT URLセクションを参照）またはリモートの名前（以下のリモートセクションを参照）のいずれかです。

<refspec>…​

どのソースオブジェクトでどの宛先リファレンスを更新するかを指定します。パラメータの形式は、オプションのプラス+、それに続くソースオブジェクト、それに続くコロン:、それに続く宛先リファレンスです。

は通常、プッシュしたいブランチの名前ですが、master~4やHEADのような任意の「SHA-1式」でもかまいません（gitrevisions[7]を参照）。

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

がrefs/で始まらない場合（例：refs/heads/master）、プッシュされるのタイプとが曖昧かどうかをに基づいて、宛先のrefs/*のどこに属するかを推測しようとします。

  • がリモート上の参照を明確に指す場合、その参照にプッシュします。

  • がrefs/heads/またはrefs/tags/で始まる参照に解決される場合、それをの前に付加します。

  • 将来的に他の曖昧さの解決が追加されるかもしれませんが、今のところ他のケースでは、試行した内容を示すエラーで失敗し、advice.pushUnqualifiedRefname設定（git-config[1]を参照）によっては、どのrefs/名前空間にプッシュしたかったかを示唆します。

によって参照されるオブジェクトは、リモート側の参照を更新するために使用されます。これが許可されるかどうかは、参照がrefs/*のどこに存在するかによって決まります。これについては以下で詳しく説明されており、これらのセクションでは「更新」は削除以外の変更を意味します。削除は次のいくつかのセクションの後に述べられているように、異なる方法で扱われます。

refs/heads/*名前空間はコミットオブジェクトのみを受け入れ、高速転送可能な場合にのみ更新を許可します。

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

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

つまり、refs/{tags,heads}/*以外のコミットとタグの高速転送は許可されます。これは、高速転送されているものがコミットではなく、最新のタグ（またはコミット）が置き換えられているコミットの高速転送である新しいコミットを指すタグオブジェクトである場合でも同様です。タグを完全に異なるタグで置き換えることも、それが同じコミットを指している場合や、剥がされたタグをプッシュする場合（つまり、既存のタグオブジェクトが指すコミットをプッシュするか、既存のコミットが指す新しいタグオブジェクトをプッシュする）も許可されます。

refs/{tags,heads}/*以外のツリーおよびブロブオブジェクトは、refs/tags/*内にあるかのように扱われ、それらへの更新は拒否されます。

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

空のをプッシュすると、リモートリポジトリから参照を削除できます。削除は、設定またはフックによって禁止されている場合を除き、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/配下の参照）をプッシュします。他のとは一緒に使用できません。

--prune

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

--mirror

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

-n
--dry-run

実際に更新を送信することを除いて、すべてを実行します。

--porcelain

機械で読み取り可能な出力を生成します。各参照の出力ステータス行はタブ区切りで、stderrではなくstdoutに送信されます。参照の完全なシンボル名が与えられます。

-d
--delete

リストされたすべての参照がリモートリポジトリから削除されます。これは、すべての参照にコロンを前置するのと同じです。

--tags

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

--follow-tags

このオプションなしでプッシュされるすべての参照をプッシュし、さらに、リモートにはないがプッシュされる参照から到達可能なコミットにポイントしているrefs/tags内のアノテートされたタグもプッシュします。これは設定変数push.followTagsでも指定できます。詳細については、git-config[1]のpush.followTagsを参照してください。

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

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

--[no-]atomic

利用可能な場合、リモート側でアトミックトランザクションを使用します。すべての参照が更新されるか、エラーが発生した場合はどの参照も更新されません。サーバーがアトミックプッシュをサポートしていない場合、プッシュは失敗します。

-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*プログラムへのパス。ssh経由でリモートリポジトリにプッシュする場合に、デフォルトの$PATHにプログラムがない場合に役立つことがあります。

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

通常、"git push" は、上書きに使用されるローカルの参照の祖先ではないリモートの参照を更新することを拒否します。

このオプションは、リモート参照の現在の値が期待される値である場合、この制限を上書きします。それ以外の場合、"git push" は失敗します。

すでに公開したものをリベースする必要がある状況を想像してください。元の公開履歴をリベースされた履歴に置き換えるために、「高速転送必須」ルールをバイパスする必要があります。リベース中に他の誰かが元の履歴に基づいて作業していた場合、リモートのブランチの先端は彼らのコミットで進む可能性があり、--forceで盲目的にプッシュすると彼らの作業が失われます。

このオプションを使用すると、更新しようとしている履歴が、リベースして置き換えたいものだと指定できます。リモート参照が指定したコミットを指しているままであれば、他の誰もその参照に対して何もしていないことを確認できます。これは、明示的にロックすることなく参照を「リース」するようなもので、リモート参照は「リース」が有効な場合にのみ更新されます。

--force-with-lease単独で、詳細を指定しない場合、更新されるすべてのリモート参照を保護します。これは、それらに対するリモート追跡ブランチの現在の値が同じであることを要求します。

--force-with-lease=<refname>は、期待値を指定しない場合、名前付き参照（単独で）が更新される場合に、その現在の値がそれに対するリモート追跡ブランチと同じであることを要求することで保護します。

--force-with-lease=<refname>:<expect>は、名前付き参照（単独で）が更新される場合に、その現在の値が指定された値<expect>と同じであることを要求することで保護します（これは、参照名に対して持っているリモートトラッキングブランチと異なってもよく、この形式を使用する場合にはそのようなリモートトラッキングブランチを持つ必要すらありません）。<expect>が空の文字列の場合、名前付き参照はまだ存在してはなりません。

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

"--no-force-with-lease" はコマンドライン上の以前のすべての --force-with-lease をキャンセルします。

安全性に関する一般的な注意点として、期待値を指定せずにこのオプションを渡すこと、つまり--force-with-leaseまたは--force-with-lease=<refname>として渡すことは、バックグラウンドでプッシュ先のリモートに対して暗黙的にgit fetchを実行するあらゆるもの（例：cronジョブでのリポジトリに対するgit fetch origin）と非常に相性が悪いです。

--forceに対する保護は、作業の基盤となっていないその後の変更が上書きされないようにすることですが、バックグラウンドプロセスが参照を更新している場合、これは簡単に無効になります。見ているはずの参照や上書きしても構わない参照のヒューリスティックとして、リモートトラッキング情報以外に頼るものはありません。

エディタや他のシステムがバックグラウンドでgit fetchを実行している場合、これを軽減する1つの方法は、別のリモートを設定することです。

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である場合にmasterへの変更を強制プッシュします。このとき、バックグラウンドでローカルのremotes/origin/masterが何に更新されているかは関係ありません。

あるいは、「プッシュ」時に--force-with-lease[=<refname>]（つまり、リモート側の参照が指すべき正確なコミットや、リモート側で保護されている参照を指定しない）とともに補助オプションとして--force-if-includesを指定すると、バックグラウンドで暗黙的に更新された可能性のあるリモートトラッキング参照からの更新がローカルに統合されているかどうかが検証され、強制更新が許可されます。

-f
--force

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

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

--forceはプッシュされるすべての参照に適用されるため、push.defaultをmatchingに設定したり、複数のプッシュ先をremote.*.pushで設定したりすると、現在のブランチ以外の参照（リモートの対応する参照よりも厳密に遅れているローカル参照を含む）が上書きされる可能性があります。1つのブランチにのみ強制プッシュするには、プッシュするrefspecの前に+を付けてください（例：git push origin +masterでmasterブランチに強制プッシュ）。詳細については、上記の<refspec>...セクションを参照してください。

--[no-]force-if-includes

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

このオプションは、リモート追跡参照の先端が、リライトのためにそのブランチに基づいたローカルブランチの「reflog」エントリのいずれかから到達可能であるかどうかを検証するチェックを有効にします。このチェックは、リモートからの更新がローカルに組み込まれていない場合に強制更新を拒否することで、それらの更新がローカルに組み込まれていることを保証します。

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

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

-v
--verbose

詳細に実行します。

--progress

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

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

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

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

--[no-]verify

pre-pushフックの有効/無効を切り替えます（githooks[5]を参照）。デフォルトは--verifyであり、フックにプッシュを防止する機会を与えます。--no-verifyを使用すると、フックは完全にバイパスされます。

-4
--ipv4

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

-6
--ipv6

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

GIT URL

一般に、URLには、転送プロトコル、リモートサーバーのアドレス、およびリポジトリへのパスに関する情報が含まれます。転送プロトコルによっては、この情報の一部が存在しない場合があります。

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

ネイティブ転送 (つまり 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は、ssh URLとして誤解されるのを避けるために、絶対パスまたは./foo:barとして指定できます。

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つの構文はほとんど同じですが、クローン作成時を除き、前者は --local オプションを意味します。詳細については、git-clone[1] を参照してください。

git clone、git fetch、git pullは、git pushは適用されませんが、適切なバンドルファイルも受け入れます。git-bundle[1]を参照してください。

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 は、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 が引き続き使用されます。

リモート

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

  • Git 設定ファイル内のリモート: $GIT_DIR/config,

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

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

これらすべてにより、コマンドラインからリファレンスを省略することもできます。それぞれに、Git がデフォルトで使用するリファレンスが含まれているためです。

設定ファイル内の名前付きリモート

git-remote[1]、git-config[1]を使用して、あるいは$GIT_DIR/configファイルを直接編集して以前に設定したリモートの名前を指定できます。このリモートのURLがリポジトリへのアクセスに使用されます。コマンドラインでrefspecを指定しない場合、このリモートのrefspecがデフォルトで使用されます。設定ファイルのエントリは次のようになります。

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

<pushurl>はプッシュのみに使用されます。これはオプションであり、デフォルトは<URL>です。リモートへのプッシュは、定義されているすべてのプッシュURL、またはプッシュURLが定義されていない場合は定義されているすべてのURLに影響します。ただし、フェッチは、複数のURLが定義されている場合でも、最初に定義されているURLからのみフェッチします。

$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:行を指定できます。

$GIT_DIR/branches 内の名前付きファイル

$GIT_DIR/branches 内のファイルの名前を指定できます。このファイル内の URL はリポジトリにアクセスするために使用されます。このファイルは次の形式である必要があります。

	<URL>#<head>

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

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

git fetch の使用

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

git push の使用

	HEAD:refs/heads/<head>

出力

"git push" の出力は使用される転送方法によって異なります。このセクションでは、Gitプロトコル（ローカルまたはssh経由）でプッシュする場合の出力を説明します。

プッシュのステータスは表形式で出力され、各行は単一の参照のステータスを表します。各行は次の形式です。

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

--porcelain が使用された場合、出力の各行は次の形式になります。

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

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

フラグ

参照のステータスを示す一文字

(空白)

成功した高速転送の場合。

+

強制更新が成功した場合。

-

正常に削除された参照の場合。

*

正常にプッシュされた新しい参照の場合。

!

拒否されたか、プッシュに失敗した参照の場合。そして

=

最新であり、プッシュする必要がなかった参照の場合。

要約

正常にプッシュされた参照の場合、要約は参照の古い値と新しい値をgit logの引数として使用するのに適した形式で表示します（ほとんどの場合、これは<old>..<new>であり、強制された非高速転送更新の場合は<old>...<new>です）。

更新に失敗した場合、詳細が表示されます。

拒否された

Gitは参照を送信しようとしませんでした。これは通常、高速転送ではなく、更新を強制しなかったためです。

リモートで拒否されました

リモート側が更新を拒否しました。通常、リモート側のフックによって、またはリモートリポジトリが以下の安全オプションのいずれかを有効にしているためです。receive.denyCurrentBranch（チェックアウトされたブランチへのプッシュの場合）、receive.denyNonFastForwards（強制的な非高速転送更新の場合）、receive.denyDeletesまたはreceive.denyDeleteCurrent。git-config[1]を参照してください。

リモート障害

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

元

プッシュされているローカル参照の名前で、refs/<type>/プレフィックスを除いたものです。削除の場合、ローカル参照の名前は省略されます。

宛先

更新されるリモート参照の名前で、refs/<type>/プレフィックスを除いたものです。

理由

人間が読める説明です。正常にプッシュされた参照の場合、説明は不要です。失敗した参照の場合、失敗の理由が説明されます。

高速転送に関する注意

更新によって、コミット A を指していたブランチ（またはより一般的には参照）が別のコミット B を指すように変更された場合、B が A の子孫である場合に限り、それは高速転送更新と呼ばれます。

A から B への高速転送更新では、元のコミット A が構築されたコミットの集合は、新しいコミット B が構築されたコミットの集合の部分集合です。したがって、履歴は失われません。

対照的に、非高速転送更新は履歴を失います。例えば、あなたと他の誰かが同じコミット X から開始し、あなたがコミット B に至る履歴を構築し、他の人がコミット A に至る履歴を構築したとします。履歴は次のようになります。

      B
     /
 ---X---A

さらに、他の人がすでにコミット A に至る変更を、あなたが元々コミット X を取得した元のリポジトリにプッシュしたとします。

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

しかし、あなたがプッシュしようとすると、ブランチ（現在Aを指している）をコミットBで更新しようとします。これは高速転送*ではありません*。もしそうした場合、コミットAによって導入された変更は失われます。なぜなら、誰もがBに基づいて構築を開始するようになるからです。

このコマンドはデフォルトで、このような履歴の損失を防ぐために、高速転送ではない更新を許可しません。

自分の作業（XからBへの履歴）や他の人の作業（XからAへの履歴）を失いたくない場合は、まずリポジトリから履歴をフェッチし、両者が行った変更を含む履歴を作成し、その結果をプッシュし直す必要があります。

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

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

A を結果のマージコミットで更新すると、高速転送され、プッシュが受け入れられます。

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

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

繰り返しになりますが、このコミットでAを更新すると、高速転送され、プッシュが受け入れられます。

プッシュしようとしたときに非高速転送の拒否に遭遇するもう1つの一般的な状況があります。これは、他の誰もプッシュしないリポジトリにプッシュしている場合でも発生する可能性があります。自分でコミットAをプッシュした後（このセクションの最初の図）、"git commit --amend"でそれをコミットBに置き換え、すでにAをプッシュしたことを忘れてそれをプッシュしようとします。このような場合、その間に誰もあなたの以前のコミットAをフェッチしなかった（そしてそれに基づいて構築を開始しなかった）と確信できる場合に限り、"git push --force"を実行してそれを上書きできます。言い換えれば、"git push --force"は、履歴を失うことを本当に意図している場合にのみ使用される方法です。

例

git push

git push <remote>のように動作します。ここで<remote>は現在のブランチのリモート（または現在のブランチにリモートが設定されていない場合はorigin）です。

git push origin

追加の設定なしで、現在のブランチと同じ名前であれば、現在のブランチを構成されたアップストリーム（branch.<name>.merge設定変数）にプッシュし、そうでなければプッシュせずにエラーになります。

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

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

git push origin :

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

git push origin master

ソースリポジトリでmasterに一致する参照（おそらくrefs/heads/master）を見つけ、originリポジトリの同じ参照（例：refs/heads/master）で更新します。masterがリモートに存在しない場合、作成されます。

git push origin HEAD

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

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

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

マッチングセマンティクスの議論については、上記の<refspec>...を記述したセクションを参照してください。

これは、satelliteで行われた作業を統合するために、mothershipで実行されたgit fetchを、逆方向に実行されたgit pushを使用してエミュレートするためのものです。これは、一方向の接続しかできない場合（つまり、satelliteはmothershipにsshできるが、後者がファイアウォールの内側にあるかsshdを実行していないためmothershipはsatelliteに接続を開始できない場合）にしばしば必要になります。

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

git push origin HEAD:master

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

git push origin master:refs/heads/experimental

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

git push origin :experimental

originリポジトリでexperimentalに一致する参照（例：refs/heads/experimental）を見つけて、削除します。

git push origin +dev:master

非高速転送更新を許可して、originリポジトリのmasterブランチをdevブランチで更新します。**これにより、originリポジトリに参照されていないコミットがぶら下がる可能性があります。**高速転送が不可能な次の状況を考慮してください。

	    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コマンドによって削除されます。

セキュリティ

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

既知の攻撃ベクトルは以下の通りです。

  1. 被害者は、「have」行を送信して、明示的に共有することを意図していないが、ピアも持っている場合に転送を最適化するために使用できるオブジェクトのIDを宣伝します。攻撃者は盗むオブジェクトID Xを選択し、Xへの参照を送信しますが、被害者がすでに持っているためXの内容を送信する必要はありません。これで被害者は攻撃者がXを持っていると信じ、後でXの内容を攻撃者に送信します。（この攻撃は、クライアントがアクセスできる名前空間にXへの参照を作成し、それをフェッチすることで、クライアントがサーバーに対して実行するのが最も簡単です。サーバーがクライアントに対して実行する最も可能性の高い方法は、Xを公開ブランチに「マージ」し、ユーザーがこのブランチで追加作業を行い、マージに気付かずにサーバーにプッシュし直すことを期待することです。）

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

設定

このセクションのこの行より下のすべての内容は、git-config[1] ドキュメントから選択的に含まれています。内容はそちらで見られるものと同じです。

push.autoSetupRemote

"true"に設定されている場合、現在のブランチにアップストリームトラッキングが存在しない場合、デフォルトのプッシュで--set-upstreamを想定します。このオプションは、push.defaultオプションの_simple_、_upstream_、_current_で有効になります。これは、新しいブランチをデフォルトのリモートにプッシュし（_push.default=current_の動作のように）、アップストリームトラッキングも設定したい場合に便利です。このオプションから最も恩恵を受けるワークフローは、すべてのブランチがリモートで同じ名前を持つことが期待される_simple_な中央ワークフローです。

push.default

refspecが指定されていない場合（コマンドライン、設定、またはその他の場所から）、git pushがとるアクションを定義します。さまざまな値は特定のワークフローに適しています。たとえば、純粋な中央ワークフロー（フェッチ元がプッシュ先と同じ）では、upstreamが最適でしょう。可能な値は次のとおりです。

  • nothing - refspecが指定されない限り、何もプッシュしません（エラーを出します）。これは主に、常に明示的であることで間違いを避けたい人のためのものです。

  • current - 現在のブランチを受信側で同じ名前のブランチを更新するようにプッシュします。中央ワークフローと非中央ワークフローの両方で機能します。

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

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

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

    集中型ワークフロー（プル元と同じリポジトリにプッシュする、通常はorigin）で作業している場合、同じ名前でアップストリームブランチを設定する必要があります。

    このモードはGit 2.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_に設定できます。真の値は、git-push[1]に--signedが渡されたかのように、すべてのプッシュにGPG署名を強制します。文字列_if-asked_は、サーバーがサポートしている場合にのみプッシュに署名するようにし、まるでgit pushに--signed=if-askedが渡されたかのようです。偽の値は、優先度の低い設定ファイルからの値を上書きする場合があります。明示的なコマンドラインフラグは、常にこの設定オプションを上書きします。

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"と同じ動作をします。設定されていない場合、_no_がデフォルトで使用されます。ただし、_submodule.recurse_が設定されている場合（その場合、_true_値は_on-demand_を意味します）。

push.useForceIfIncludes

"true" に設定されている場合、コマンドラインでgit-push[1]にオプションとして--force-if-includesを指定するのと同等です。プッシュ時に--no-force-if-includesを追加すると、この設定は上書きされます。

push.negotiate

"true" に設定されている場合、クライアントとサーバーが共通のコミットを見つけようと試みる交渉のラウンドによって、送信されるパックファイルのサイズを削減しようとします。"false" の場合、Git は共通のコミットを見つけるためにサーバーの参照広告のみに依存します。

push.useBitmaps

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

GIT

git[1]スイートの一部

scroll-to-top