git-push(1) Manual Page

The "remote" repository that is the destination of a push operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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