git-push

コマンド名

「git-push」：関連するオブジェクトとともにリモート参照を更新します

概要

git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
         [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
         [-u | --set-upstream] [-o <string> | --push-option=<string>]
         [--[no-]signed|--signed=(true|false|if-asked)]
         [--force-with-lease[=<refname>[:<expect>]]]
         [--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 URLSのセクションを参照）またはリモートの名前（以下のREMOTES のセクションを参照）のいずれかです。

<refspec>…

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

<src>はプッシュするブランチの名前であることがよくありますが、master~4やHEAD などの任意の「SHA-1式」にすることができます（gitrevisions[7]を参照）。

<dst>はこのプッシュでリモート側のどの参照が更新されるかを示します。ここでは任意の式を使用できません。実際の参照には名前を付ける必要があります。<refspec> 引数なしのgit push [<repository>]は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 / namespace」を提案します。

<src>によって参照されるオブジェクトはリモート側の<dst>参照を更新するために使用されます。 これが許可されるかどうかはrefs/* のどこに<dst>参照が存在するかによって異なります。これらのセクションでは「更新」とは削除以外の変更を意味します。削除は次のいくつかのセクションの後で異なる方法で処理されます。

refs/heads/* 名前スペースはコミットオブジェクトのみを受け入れ、ファーストフォワードできる場合にのみ更新します。

refs/tags/* 名前スペースはあらゆる種類のオブジェクトを受け入れ（コミット、ツリー、ブロブにタグを付けることができるため）、それらへの更新はすべて拒否されます。

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

つまりrefs/{tags,heads}/* の外部でのコミットとタグのファーストフォワードはファーストフォワードされているのがコミットではなく、たまたま新しいコミットを指すタグオブジェクトである場合でも許可されます。置き換えられる最後のタグ（またはコミット）のコミットをファーストフォワードします。タグが同じコミットを指している場合、タグを完全に異なるタグに置き換えることもできます。またピーリングされたタグをプッシュすることもできます。つまり既存のタグオブジェクトが指すコミット、または既存のコミットが指す新しいタグオブジェクトをプッシュします。

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

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

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

特別な参照スペック: (または+:非ファーストフォワード更新を許可する）はGitに「一致する」ブランチをプッシュするように指示します。ローカル側に存在するすべてのブランチについて、同じ名前のブランチがすでに存在する場合、リモート側が更新されます。

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

--all

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

--prune

ローカルに対応するものがないリモートブランチを削除します。例えば、同じ名前のローカルブランチが存在しなくなった場合、リモートブランチtmpは削除されます。これは参照スペックを優先します。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

コマンドラインに明示的にリストされている参照スペックに加えて、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>

指定された文字列をサーバーに送信します。サーバーはそれらを受信前フックと受信後フックにパスします。指定された文字列には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」は上書きに使用されたローカル参照の祖先ではないリモート参照の更新を拒否します。

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

すでに公開したものをリベースする必要があると想像してください。最初に公開した履歴をリベースされた履歴に置き換えるには「ファーストフォワードする必要がある」ルールをバイパスする必要があります。あなたがリベースしている間に他の誰かがあなたのオリジナル履歴の上に構築した場合、リモートのブランチの末端がコミットで前進する可能性があり、--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 を暗黙的に実行するものと非常に悪い相互作用をします。バックグラウンドでプッシュされます、例えばクローンジョブにおけるレポジトリの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

つまり ローカルのremotes/origin/master に関係なくバックグランドで更新され、リモートバージョンがまだbaseにある場合、確認したアップストリームコードのバージョンのbaseタグを作成し、上書きしてから履歴を書き換え、最後にプッシュ変更をマスターに強制します。

-f
--force

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

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

<p>---force はプッシュされるすべての参照に適用されるため、push.default をmatchingに設定するか、remote.*.push で構成された複数のプッシュ先で使用すると、現在のブランチ以外の参照（リモートカウンターパートの背後にあるローカル参照を含む）が上書きされる可能性があることに注意してください。1つのブランチのみにプッシュを強制するには参照スペックの前に+を使用してプッシュします（例えば、git push origin +masterを使用して、masterブランチにプッシュを強制します）。詳細については上記の<refspec>... セクションを参照してください。

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

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

--[no-]verify

プレプッシュフックを切り替えます（githooks[5]を参照）。デフォルトは「–verify」でフックにプッシュを防ぐ機会を与えます。「–no-verify」を使用するとフックは完全にバイパスされます。

-4
--ipv4

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

-6
--ipv6

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

GITのURL

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

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

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

次のシンタックスを使用できます。

  • ssh://[user@]host.xz[:port]/path/to/repo.git/
  • git://host.xz[:port]/path/to/repo.git/
  • http[s]://host.xz[:port]/path/to/repo.git/
  • ftp[s]://host.xz[:port]/path/to/repo.git/

代替のscpのようなシンタックスもsshプロトコルで使用できます。

  • [user@]host.xz:path/to/repo.git/

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

sshおよびgitプロトコルはさらに「〜username」拡張をサポートします。

  • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
  • git://host.xz[:port]/~[user]/path/to/repo.git/
  • [user@]host.xz:/~[user]/path/to/repo.git/

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はリポジトリへのアクセスに使用されます。コマンドラインで参照スペックを指定しない場合、このリモートの参照スペックがデフォルトで使用されます。構成ファイルのエントリは次のようになります。

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

<pushurl>はプッシュにのみ使用されます。これはオプションであり、デフォルトは<url>です。

$GIT_DIR/remotes内の名付けられたファイル

$GIT_DIR/remotesでファイルの名前を指定することを選択できます。このファイルのURLはリポジトリへのアクセスに使用されます。コマンドラインで参照スペックを指定しない場合、このファイルの参照スペックがデフォルトとして使用されます。このファイルのフォーマットは次のとおりです。

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

Push: ラインは「git push」によって使用され、Pull:ラインは「gitpull」および「gitfetch」によって使用されます。複数のPush:とPull: ラインは追加のブランチマッピング用に指定できます。

$GIT_DIR/branches内の名付けられたファイル

$GIT_DIR/branchesでファイルの名前を指定することを選択できます。このファイルのURLはリポジトリへのアクセスに使用されます。このファイルのフォーマットは次のとおりです。

<url>#<head>

<url> が必要です。#<head>はオプションとなっています。

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

gitfetchは次のように使用します。

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

git pushは次のように使用します。

HEAD:refs/heads/<head>

出力

「gitpush」の出力は使用するトランスポート方法によって異なります。このセクションではGitプロトコルを（ローカルまたはssh経由で）プッシュするときの出力について説明します。

プッシュのステータスは表形式で出力され、各ラインはシングル参照のステータスを表します。各ラインの形式は次のとおりです。

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

「–porcelain」が使用されている場合、出力の各ラインは次の形式になります。

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

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

flag

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

(space)

ファーストフォワードに成功させるため。

+

強制更新を成功させるため。

-

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

*

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

!

拒否された、またはプッシュに失敗した参照のため。

=

最新でプッシュする必要がなかった参照のため。

summary

正常にプッシュされた参照の場合、要約にはgit log への引数として使用するのに適した形式で参照の古い値と新しい値が表示されます（これはほとんどの場合<old>..<new>であり、<old>...<new> 強制的な非ファーストフォワードの場合です）。
失敗した更新については詳細が示されます。

rejected

Gitは参照を送信しません。これは通常、ファーストフォワードではなく、強制的に更新しなかったためです。

remote rejected

リモートエンドは更新を拒否します。通常、リモート側のフックが原因で発生するかリモートリポジトリに次の安全オプションのいずれかが有効になっているためです。

receive.denyCurrentBranch （チェックアウトされたブランチへのプッシュ用）

receive.denyNonFastForwards （強制的な非ファーストフォワード更新用）

receive.denyDeletesまたはreceive.denyDeleteCurrent。git-config[1]を参照してください。

remote failure

リモートエンドはおそらくリモート側での一時的なエラー、ネットワーク接続の切断、またはその他の一時的なエラーのために参照の正常な更新をレポートしません。

from

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

to

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

reason

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

ファーストフォワードについての注記

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

AからBへのファーストフォワード更新ではオリジナルコミットAの上に構築されたコミットのセットは新しいコミットBの上に構築されたコミットのサブセットです。したがって、履歴が失われることはありません。

対照的にファーストフォワードでない更新は履歴を失います。例えば、あなたと他の誰かが同じコミットXで開始し、コミットBにつながる履歴を作成し、他の人がコミットAにつながる履歴を作成したとします。履歴は次のようになります。

       B
     /
---X---A

さらに、他の人がすでにAにつながる変更をプッシュして、2人がオリジナルコミットXを取得したオリジナルリポジトリに戻したとします。

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

ただし、プッシュしようとすると、コミットBを使用してブランチ（現在はAを指している）を更新しようとします。これはファーストフォワードではありません。そうするとコミットAによって導入された変更は失われます。これは全員がBの上に構築を開始するためです。

このコマンドはデフォルトではこのような履歴の損失を防ぐためのファーストフォワードではない更新を許可していません。

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

「gitpull」を実行し、潜在的なコンフリクトを解決して、結果を「gitpush」することができます。 「gitpull」はコミットAとBの間にマージコミットCを作成します。

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

結果のマージコミットでAを更新すると、ファーストフォワードされ、プッシュが受け入れられます。

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

      BD
    / /
---X---A

繰り返しますが、このコミットでAを更新するとファーストフォワードされ、プッシュが受け入れられます。

プッシュしようとしたときにファーストフォワードではない拒否が発生する可能性がある別の一般的な状況があり、他の誰もプッシュしていないリポジトリにプッシュしている場合でも発生する可能性があります。自分でコミットAをプッシュした後（このセクションの最初の図）、それを「git commit –amend」に置き換えてコミットBを作成し、すでにAをプッシュしたことを忘れたため、プッシュしようとします。このような場合、その間に誰も以前のコミットAをフェッチしなかった（そしてその上にビルドを開始した）ことが確実な場合にのみ、「gitpush–force」を実行して上書きできます。 言い換えれば「git push –force」は履歴を失うことを意味する場合のために予約されているメソッドなのです。

例

git push

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

git push origin

追加の構成がない場合、現在のブランチが現在のブランチと同じ名前の場合、構成されたアップストリーム（remote.origin.merge 構成変数）にプッシュし、それ以外の場合はプッシュせずにエラーになります。

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

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

git push origin :

「一致する」ブランチをoriginにプッシュします。 「matching」ブランチの説明については上記のOPTIONSセクションの<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で行われたワークを統合するために反対方向に実行されるgit push を使用して、mothershipで実行されるgit fetch をエミュレートするためであり、一方向でしか接続できない場合があります（つまり、サテライトがマザーシップにSSH接続できる場合に必要になることがよくあります。ただし、サテライトがファイアウォールの背後にあるか、sshdを実行していないため、サテライトへの接続を開始できません）。

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ブランチを作成します。 このフォームはローカル名とリモート名が異なる場合、リモートリポジトリに新しいブランチまたはタグを作成するためにのみ必要です。それ以外の場合は参照名自体が機能します。

git push origin :experimental

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

git push origin +dev:master

オリジンリポジトリの「master」ブランチを「dev」ブランチで更新し、ファーストフォワード以外の更新を可能にします。これにより参照されていないコミットがオリジンリポジトリにぶら下がる可能性があります。ファーストフォワードが不可能な次の状況を考えてみます。

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

上記のコマンドはオリジンリポジトリをに変更します。

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

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

セキュリティ

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

既知の攻撃ベクトルは次のとおりです。

        1. 被害者は明示的に共有することを意図していないオブジェクトのIDをアドバタイズする「have」ラインを送信しますが、ピアにもIDがある場合、転送を最適化するために使用できます。攻撃者はオブジェクトIDXを選択して盗み、参照をXに送信しますが被害者はすでにXのコンテンツを持っているため、Xのコンテンツを送信する必要はありません。これで被害者は攻撃者がXを持っていると信じ、Xのコンテンツを後で攻撃者に送り返します（この攻撃はクライアントがアクセスできる名前スペースにXへの参照を作成し、それをフェッチすることで、クライアントがサーバー上で実行するのが最も簡単です。サーバーがクライアント上で実行する最も可能性の高い方法は「 Xをパブリックブランチにマージし、ユーザーがこのブランチで追加のワークを行い、マージに気付かずにサーバーにプッシュバックすることを期待します）。
        2. ＃1と同様に攻撃者は盗むオブジェクトIDXを選択します。被害者は攻撃者がすでに持っているオブジェクトYを送信し、攻撃者はYではなくXを持っていると誤って主張するため、被害者はYをXに対するデルタとして送信します。デルタは攻撃者にYに類似したXの領域を明らかにします。

GIT

git[1]パッケージソフトの一部

git公式ドキュメント

push

</p