日本語 ▾ トピック ▾ 最新バージョン ▾ 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`値に相当します: 現在のブランチは対応する上流ブランチにプッシュされますが、安全対策として、上流ブランチがローカルブランチと同じ名前でない場合、プッシュは中断されます。

オプション

<リポジトリ>

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

<refspec>…​

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

<src>は通常プッシュしたいブランチの名前ですが、`master~4`や`HEAD`のような任意の「SHA-1表現」でも構いません (gitrevisions[7]を参照)。

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

<dst>が`refs/`で始まらない場合（例: `refs/heads/master`）、プッシュされる<src>のタイプと<dst>があいまいであるかどうかに基づいて、宛先<repository>の`refs/*`内のどこに属するかを推測しようとします。

  • <dst>が<repository>リモート上のリファレンスを明確に指す場合、そのリファレンスにプッシュします。

  • <src>が`refs/heads/`または`refs/tags/`で始まるリファレンスに解決される場合、それを<dst>の前に付加します。

  • 将来的には他のあいまいさの解決策が追加される可能性がありますが、今のところ、それ以外のケースでは、試行された内容を示すエラーが発生し、`advice.pushUnqualifiedRefname`設定 (git-config[1]を参照) に応じて、プッシュしたかった`refs/`名前空間を示唆します。

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

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

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

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

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

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

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

空の<src>をプッシュすることで、リモートリポジトリから<dst>リファレンスを削除できます。削除は、設定やフックによって禁止されている場合を除き、refspecの先頭に`+`（または`--force`）がなくても常に受け入れられます。git-config[1]の`receive.denyDeletes`、およびgithooks[5]の`pre-receive`と`update`を参照してください。

特殊なrefspecである`:`（またはnon-fast-forward更新を許可するための`+:`）は、Gitに「一致する」ブランチをプッシュするように指示します。ローカル側に存在するすべてのブランチについて、リモート側に同じ名前のブランチが既に存在する場合、リモート側が更新されます。

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

--all
--branches

すべてのブランチ（つまり`refs/heads/`以下のリファレンス）をプッシュします。他の<refspec>とは併用できません。

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

このオプションなしでプッシュされるすべてのリファレンスをプッシュし、さらにリモートに存在しないがプッシュされるリファレンスから到達可能なcommit-ishを指す`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」は失敗します。

すでに公開したものをリベースする必要があると考えてください。元々公開した履歴をリベースされた履歴に置き換えるには、「必ずfast-forwardする」というルールを迂回する必要があります。リベース中に誰かがあなたの元の履歴の上に構築した場合、リモートブランチの先端が彼らのコミットによって進む可能性があり、`--force`で盲目的にプッシュすると彼らの作業が失われます。

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

`--force-with-lease`のみで、詳細を指定しない場合、更新されるすべてのリモートリファレンスを保護し、それらの現在の値が、それらのリモート追跡ブランチと同じである必要があるとします。

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

`--force-with-lease=<refname>:<expect>`は、更新される対象の名前付きリファレンス（単独で）を保護し、その現在の値が指定された値`<expect>`と同じである必要があるとします（この値は、そのrefnameのリモート追跡ブランチと異なっていても構いませんし、この形式を使用する際にそのようなリモート追跡ブランチを持っている必要すらありません）。`<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`を実行している場合、これを緩和する一つの方法は、単にもう一つリモートを設定することです

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`への変更を強制プッシュします。

あるいは、「push」時に`--force-with-lease[=<refname>]`と共に`--force-if-includes`を補助オプションとして指定する（つまり、リモート側のリファレンスがどの正確なコミットを指している必要があるか、またはリモート側のどのリファレンスが保護されているかを言及しない）と、バックグラウンドで暗黙的に更新された可能性のあるリモートトラッキングリファレンスからの更新がローカルに統合されているかを確認してから、強制更新を許可します。

-f
--force

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

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

`--force`はプッシュされるすべてのリファレンスに適用されるため、`push.default`を`matching`に設定したり、`remote.*.push`で複数のプッシュ先を設定したりすると、現在のブランチ以外のリファレンス（リモートの対応物から厳密に遅れているローカルリファレンスを含む）を上書きする可能性があることに注意してください。単一のブランチへのプッシュを強制するには、プッシュする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>

sshプロトコルでは、scpのような代替構文も使用できます

  • [<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を使い続けます。

リモート

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

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

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

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

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

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

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

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

`<pushurl>`はプッシュ専用です。これはオプションであり、デフォルトは`<URL>`です。リモートへのプッシュは、定義されたすべてのpushurl、またはpushurlが定義されていない場合は定義されたすべての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`オプションが使用された場合にのみ表示されます。

フラグ

リファレンスのステータスを示す単一の文字

(スペース)

正常にプッシュされたfast-forwardの場合;

+

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

-

リファレンスの削除が成功した場合;

*

新しいリファレンスのプッシュが成功した場合;

!

拒否された、またはプッシュに失敗したリファレンスの場合; そして

=

最新であり、プッシュする必要がなかったリファレンスの場合。

概要

正常にプッシュされたリファレンスの場合、概要は`git log`の引数として使用するのに適した形式で、リファレンスの古い値と新しい値を示します（ほとんどの場合`<old>..<new>`、強制的なnon-fast-forward更新の場合は`<old>...<new>`です）。

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

拒否

Gitはリファレンスを全く送信しようとしませんでした。これは通常、それがfast-forwardではなく、更新を強制しなかったためです。

リモートによって拒否

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

リモート失敗

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

元

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

先

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

理由

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

FAST-FORWARDに関する注意

更新によって、かつてコミットAを指していたブランチ（またはより一般的にリファレンス）が別のコミットBを指すように変更される場合、それがfast-forward更新と呼ばれるのは、BがAの子孫である場合に限ります。

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

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

      B
     /
 ---X---A

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

他の人によって行われたプッシュは、かつてコミットXを指していたブランチをコミットAを指すように更新しました。これはfast-forwardです。

しかし、あなたがプッシュしようとすると、現在Aを指しているブランチをコミットBで更新しようとします。これは*fast-forwardではありません*。もしそうした場合、コミット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」を使ってXとBの間の変更をAの上にリベースし、その結果をプッシュし直すことができます。このリベースは、Aの上にXとBの間の変更を構築する新しいコミットDを作成します。

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

ここでも、このコミットでAを更新するとfast-forwardになり、プッシュが受け入れられます。

プッシュしようとした際にnon-fast-forward拒否に遭遇するもう一つの一般的な状況があり、これはあなたが他の誰もプッシュしないリポジトリにプッシュしている場合でも起こり得ます。自分でコミット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`設定変数）にプッシュします。そうでない場合は、プッシュせずにエラーになります。

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

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

`git push origin :`

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

`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接続できるが、`mothership`は`satellite`がファイアウォールの内側にいるかsshdを実行していないため`satellite`への接続を開始できない場合）にしばしば必要となります。

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

`git push origin HEAD:master`

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

`git push origin master:refs/heads/experimental`

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

`git push origin :experimental`

`origin`リポジトリ内で`experimental`に一致するリファレンス（例: `refs/heads/experimental`）を見つけ、それを削除します。

`git push origin +dev:master`

originリポジトリのmasterブランチをdevブランチで更新し、non-fast-forward更新を許可します。**これにより、参照されないコミットが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`コマンドによって削除されます。

セキュリティ

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

既知の攻撃ベクトルは以下のとおりです

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

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

設定

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

push.autoSetupRemote

「true」に設定されている場合、現在のブランチに上流追跡が存在しないデフォルトのプッシュ時に`--set-upstream`を仮定します。このオプションは`push.default`オプションの*simple*、*upstream*、*current*で有効です。デフォルトで新しいブランチをデフォルトのリモートにプッシュし（*push.default=current*の動作のように）、かつ上流追跡も設定したい場合に便利です。このオプションから最も恩恵を受ける可能性が高いワークフローは、すべてのブランチがリモートで同じ名前を持つことが期待される*シンプルな*中央ワークフローです。

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*を実行する前に、プッシュしたい*すべて*のブランチがプッシュ可能な状態になっていることを確認する必要があります。このモードの目的は、すべてのブランチを一度にプッシュできるようにすることだからです。通常、一つのブランチでの作業だけを終えて結果をプッシュし、他のブランチは未完成のままである場合、このモードはあなたには適していません。また、このモードは共有中央リポジトリへのプッシュには適していません。なぜなら、他の人がそこに新しいブランチを追加したり、あなたの制御外で既存のブランチの先端を更新したりする可能性があるからです。

    これは以前のデフォルトでしたが、Git 2.0以降は異なります（`simple`が新しいデフォルトです）。

push.followTags

trueに設定されている場合、デフォルトで`--follow-tags`オプションを有効にします。プッシュ時に`--no-follow-tags`を指定することで、この設定を上書きできます。

push.gpgSign

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

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