113

git nirvana を達成するために、現在マージしている状況で rebase を活用する方法を学ぶことに 1 日を費やしています。

私が git 101 フロー (以下で詳しく説明します) と見なすものを実行するpush --forceとき、変更を元に戻すときに実行する必要があります。

私だけではありません - 私はこれが覆われた地面であることを知っています ( 1 、 2 、 3 、 4 、 5を参照) 。私の問題はこれです --- リベースの賞賛とそれが彼らの生活をどのように変えたかを歌っている多くの（多くの）ブログエントリがあります（いくつかをリストするには、1、2、3、4を参照してください）。彼らの流れ。ただし、既存のstackoverflowの質問に対するほぼすべての回答は、「ええ、リベースするつもりなら、使用する必要があります」などと言っています。push --forcepush --force

リベース支持者の数と信心深さを考えると、'push --force' の使用はリベース フローに固有の部分ではなく、頻繁にプッシュを強制しなければならない場合、彼らは何か間違ったことをしていると私は信じなければなりません。

push --force悪いことです。

それでは、私の流れです。 力を使わずに同じ結果を達成するにはどうすればよいでしょうか?

簡単な例

2 つのブランチ:

  • v1.0 - パッチのみを含むリリース ブランチ
  • master - 次のメジャー リリースのすべて。

いくつかのパッチ コミットと、次のリリースのためのいくつかのコミットがあります。

マージする

次のリリースで失われないように、パッチをマスターに組み込みたいと思います。悟り前 私は単純に：

git checkout master
git merge v1.0

しかし、今私はしようとしています

git checkout master
git rebase v1.0

だから今私はここにいます：

ここに画像の説明を入力

時間:

git push

サイコロはありません。

4

6 に答える 6

46

リベースは優れたツールですが、これを使用してトピック ブランチの master への早送りマージを作成する場合に最適です。たとえば、add-new-widget ブランチを master に対してリベースできます。

git checkout add-new-widget
git rebase -i master

ブランチの master への早送りマージを実行する前に。例えば：

git checkout master
git merge --ff-only add-new-widget

これの利点は、すべての変更がマージ前に master の先端にリベースされるため、履歴に複雑なマージ コミットやマージの競合があまりないことです。2 つ目の利点は、リベースしたことgit push --forceですが、マスター ブランチの履歴を壊していないため、使用する必要はありません。

これがリベースの唯一の使用例や唯一のワークフローというわけではありませんが、私が見た中で最も賢明な使用例の 1 つです。YMMV。

于 2012-06-15T21:26:09.217 に答える
26

@CodeGnomeは正しいです。v1.0 ブランチで master をリベースするのではなく、master で v1.0 ブランチをリベースすると、すべての違いが生じます。

git checkout -b integrate_patches v1.0
git rebase master
git checkout master
git merge integrate_patches

v1.0 を指す新しいブランチを作成し、その新しいブランチをマスターの上に移動してから、V1.0 パッチの新しいバージョンをマスター ブランチに統合します。あなたは次のようなものになります：

o [master] [integrate_patches] Another patch on v1.0
o A patch on v1.0
o Another change for the next major release
o Working on the next major release
|  o [v1.0] Another path on v1.0
|  o A patch on v1.0
| /
o Time for the release

このリベースの使用方法は、公式の git ドキュメントで推奨されています。

私はあなたが正しいと思いますgit push --force：あなたが間違いを犯して、あなたが望まないものを押した場合にのみそれを使うべきです.

于 2012-06-21T12:11:07.670 に答える
22

リベースする場合はプッシュを強制する必要があり、すでに変更を公開していますよね?

私はたくさんのリベースを使用していますが、強制プッシュが問題にならないプライベートなものに公開するか (たとえば、プル リクエストの一部として GitHub で自分のクローンを作成)、または初めてプッシュする前にリベースします。

これは、リベースを使用するワークフローの中心ですが、プッシュをあまり強制しないでください。準備が整うまでは公開しないでください。プッシュ後にリベースしないでください。

于 2012-06-15T21:20:35.980 に答える
5

誤ったプッシュの結果ではない、このリベース後に強制プッシュするパターンには、良いユースケースがあると思います: 複数の場所 (コンピューター) から自分で機能ブランチに取り組んでいます。私はデスクトップでオフィスで仕事をすることもあれば、ラップトップで自宅/顧客サイトから仕事をすることもあるので、これを頻繁に行います。メインブランチに遅れずについていくため、および/またはマージをよりクリーンにするために、時々リベースする必要がありますが、あるマシンを離れて別のマシンで作業するときは、強制的にプッシュする必要もあります (プルするだけです)。ブランチで作業しているのは私だけである限り、魅力のように機能します。

于 2014-06-24T14:45:33.343 に答える
4

これが私が使用するものです（ブランチ名がfoobarであると仮定します）：

git checkout master              # switch to master
git rebase   foobar              # rebase with branch
git merge -s ours origin/master  # do a basic merge -- but this should be empty
git push origin master           # aaand this should work
于 2015-01-21T23:53:15.407 に答える