2 つのシナリオを想定してみましょう。
共有開発者ブランチで直接作業: リベース後のプッシュも、このリベースの前に行われたすべてのコミットを送信しますか?
別のテストブランチで作業し、開発者ブランチにマージします。リベース後に開発者ブランチをプッシュすると、早送りモードであっても、リベースとその後のマージ (テスト->開発者) の前に行われたすべてのコミットが送信されますか? ?
Schleis の答えは正しいですが、もう少し深く掘り下げると、a の「通常の」(最適化された) プロセスは次のようになります。お使いのコンピューターを擬人化して1 /git-push-process と呼び、それを「ボブ」と呼び、問題のリモートも「レム」と呼びます。交換は次のようになります。git push [remote [refspecs ...]]
BOB: 「こんにちは、ブランチ refspec があります。何をお持ちですか?」
REM: "私はmaster
、deploy
、develop
、およびを持っていtest
ます。"
BOB: 「よし、私はの頭として、そしてcabfa4e
の頭としてコミットしている。あなたが必要とするものをあなたに送りたい。」develop
fedcafe
test
REM: 「まあ、私はすでにオンfedcafe
になっていますtest
が、まだbadf00d
オンになっていdevelop
ます...」
BOB: 「ああ、わかりbadf00d
ました。これらの新しいコミットとツリー/ブロブ/タグ オブジェクトを提供します [「薄い」パックとしてパックされたオブジェクト データの長いリストを渡します]。」
REM: [一時停止してパックを消化し、さまざまなフックを実行し、ボブが提供しているものに問題がないことと、更新しても問題ないことを確認しdevelop
ます。すべてがうまくいけば] 「ありがとう、ボブ!」
BOB: 「さようなら、またね!」
(この会話が終わると、Bob は Rem-the-remote がcabfa4e
branchdevelop
でオンになっていることを知っているので、Bob も更新しremotes/rem/develop
ます。)
これらすべてのポイントは、Bob と Rem がデータを交換し、Bob が新しい git オブジェクト (コミット、ツリー、ブロブ、および/または注釈付きタグ)。それらが完了すると、Rem は Bob が送信したものを受け取り、彼がそれを "受け取った" (参照の更新を "拒否" しなかった) 場合、Bob は Rem が持っているものの記録を更新します。
同様に重要なこととして、Bob は単に Rem に refspec を渡します。
1 つ以上のコミットを「巻き戻し」(「削除」) し、 からcabfa4e
に戻りbadf00d
、強制プッシュを行うことにしたとしましょう。会話は少し短くなります — Rem はすでにすべてのオブジェクトを持っています — そして、Rem が「いいえ、できません。私はコミットを巻き戻さないからです」と言う可能性がはるかに高くなります。ボブは、プッシュを「強制」するように要求したことをレムに伝えます(レムは「いいえ」と言うことができますが、「組み込みのデフォルト」は「強制しない限り」ではなく、「強制」を要求しました)。
または、何も巻き戻すことに決めていなかったが、Rem が Jan から新しいコミットを取得しており、Bob のコンピューターにそれらがない場合を考えてみましょう。Rem にはdevelop
at commitc0ffeee
がありますが、Bob にはまったくありません。それらの最も早い同期点は (まだ)badf00d
です。ボブはレムにプロポーズすることdevelop
ができcabfa4e
ます。レムは「いいえ、あなたは何かを見逃しています(つまり、それは早送りではありません。力を言わない限り、私はそれをしません.」と言うでしょう. 取得して (マージ/リベース)、Bob を更新する(そしておそらく他のコミットも) のはあなた次第です。badf00d
cabfa4e
c0ffeee
それはすべてコミットグラフに関するものです。あなたは (Bob 経由で) リモート (Rem) に、Rem のコミットグラフの一部を変更することを提案しrefs/heads/
ます。ラベルを別のコミットを指すように変更します。あなた (Bob) は、グラフの新しい部分と、必要なその他のオブジェクトを提供します。次に、リモート (Rem) は、Rem のルール (フック) に従って「OK」または「OK ではない」と言います。デフォルトの組み込みルールは次のとおりですrefs/heads/
。
1「コンピューターを擬人化しないでください。彼らはそれを嫌います。」
git push
リモート リポジトリを、プッシュしているローカル ブランチと同じ状態に更新しようとします。したがって、履歴に互換性がある場合、そのブランチにあるコミットはすべてリモートに追加されます。単一のコミットをプッシュするのではなく、ブランチ全体の状態をプッシュします。