git-push(1) Manual Page

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

<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> があいまいかどうかから、それが refs/* 上のどこに属するか推測しようとします。

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

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

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

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

つまり、refs/{tags,heads}/* の外部でのコミットやタグの早送りは、早送りされるものがコミットではなく、たまたま置き換えられる最後のタグ(またはコミット)の早送りである新しいコミットを指しているタグオブジェクトであっても、許可されます。 タグを全く別のタグに置き換えることも、同一のコミットを指していれば可能です。また、剥かれたタグ(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> と同じ意味です。

リモートrefの現在の値が期待の(expect)値である場合、このオプションはこの制限をオーバーライドします。 それ以外の場合、「git push」は失敗します。

あなたが、すでに公開しているものをリベースする必要があると想像してください。 最初に公開した履歴をリベースされた履歴に置き換えるには、「早送りしなければならない」ルールをバイパスする必要があります。 あなたのリベース作業中に他の誰かがあなたの元の履歴の上に構築した場合、リモートのブランチの先端は彼らのコミットで前進するかもしれません、そして、あなたが --force を伴って盲目的にプッシュすると彼らの作業内容は失われてしまいます。

このオプションを使用すると、更新している履歴がリベースされ、置き換えたいものであると期待していると言う事ができます。 リモート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 fetch origin を実行するときは、 origin-push の参照は更新されないため、以下のようにコマンドを実行します:

これは、あなたが手動で git fetch origin-push を実行しない限り、失敗するでしょう。 もちろん、この方法は git fetch --all の実行によって完全に破綻します。この場合、あなたはそれを無効にするか、以下のようになもっと退屈なことをする必要があります:

つまり、上流のコードを見て、上書きしても良いと思ったバージョンの base タグを作成し、履歴を書き換え、最後にリモートバージョンがまだ base にあれば、ローカルの remotes/origin/master がバックグラウンドで何を更新したかに関わらず、変更を master に強制的にプッシュします。

あるいは、 --force-with-lease[=<refname>] と共に補助オプションとして --force-if-includes を指定すると(つまり、リモート側の ref が正確にどのコミットを指す必要があるか、あるいはリモート側のどの ref を保護しているのかを明示せずに)、 プッシュ時に、バックグラウンドで暗黙的に更新されていたかもしれないリモート追跡 ref からの更新がローカルで統合されているかを、強制更新ができる前に確認することができるようになります。

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

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

このオプションを使用すると、リモートトラッキング参照の先端が、書き換えのためにそれに基づいているローカルブランチの「ref log」エントリの1つから到達可能かどうかを確認(verify)するチェックが有効になります。 このチェックでは、リモートからの更新がローカルに取り込まれていない場合、強制更新を拒否することで、更新がローカルに取り込まれていることを確認します。

オプションが --force-with-lease を指定せずに渡された場合、または --force-with-lease=<refname>:<expect> と一緒に指定された場合、それは「何もしません」(no-op)。

--no-force-if-includes を指定すると、この振る舞いが無効になります。

失敗した更新については、以下の詳細が示されます:

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

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

マッチングのセマンティクスの説明については、 上記「<refspec>…」について説明しているセクションを参照してください。

これは、 mothership で実行される git fetch を、 satellite での作業を統合するために逆方向に実行される git push でエミュレートするもので、一方通行でしか接続できないときによく必要になります(つまり、 satellite はsshで mothership に入ることができますが、 satellite がファイアウォールの背後にあるか、sshdを実行していないため、 mothership は `satellite`への接続を開始できません)。

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

上記コマンドは、originリポジトリを以下のように変更します

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