web-dev-qa-db-ja.com

強制プッシュを必要とせずにgit rebaseを使用するにはどうすればよいですか？

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

Git 101フローと考えられるもの（以下に説明します）を実行するとき、変更をOriginにプッシュするときにPush --forceする必要があります。

私はこれだけではありません-これはカバーされていることを知っています（ 1 、 2 、 3 、 4 、 5 ）、技術的な理由を理解しているなぜ力が必要です。私の問題はこれです---リベースの賞賛とそれが彼らの人生をどのように変えたかを歌う多くの（多くの）ブログエントリがあります（ 1 、 2を参照） 、 3 、 4 いくつか挙げます）、しかし、それらのどれもPush --forceに言及していないその流れの一部です。ただし、既存のstackoverflowの質問に対するほぼすべての答えは、「ええ、リベースする場合は、Push --forceを使用する必要があります」と言っています。

リベース支持者の数と宗教を考えると、「プッシュ--force」を使用することはリベースフローに固有の部分ではなく、頻繁にプッシュを強制する必要がある場合は、 、彼らは何か間違っている。

Push --forceは 悪いことです 。

これが私の流れです。 どのような方法で、力なしで同じ結果を達成できますか？

簡単な例

2つのブランチ：

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

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

premerge

パッチをマスターに組み込み、次のリリースで失われないようにします。啓発前私はただ：

git checkout master
git merge v1.0

しかし、今私はしようとしている

git checkout master
git rebase v1.0

だから今私はここにいる：

enter image description here

の時間：

git Push

サイコロなし。

gitgit-rebase
78
Roy Truelove

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

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

ブランチをマスターに早送りマージする前に。例えば：

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

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

それは確かにリベースの唯一のユースケースでも、唯一のワークフローでもありませんが、私が見た中で最も賢明な用途の1つです。 YMMV。

38
Todd A. Jacobs

@CodeGnomeは正しい。マスターをv1.0ブランチにリベースするのではなく、マスターに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：間違いを犯し、望まないものをプッシュした場合にのみ使用してください。

22
Fabien Quatravaux

リベースする場合、Pushを強制する必要がありますand変更を既に公開していますか？

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

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

14
Daniel Pittman

このrebase-then-force-pushパターンには、誤ったプッシュの結果ではなく、複数の場所（コンピューター）から機能ブランチを自分で操作するのに適したユースケースがあると思います。私はデスクトップでオフィスで働いたり、ラップトップで自宅/顧客サイトから働いたりすることがあるため、これを頻繁に行います。メインブランチに追いつくため、および/またはマージをクリーンにするために時々リベースする必要がありますが、1つのマシンを離れて別のマシン（引っ張るだけ）で作業するときに強制プッシュする必要もあります。私だけがブランチで作業している限り、魅力のように機能します。

5
8forty

私が使用するものは次のとおりです（ブランチ名が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
2
redolent