如何在不需要強制推送的情況下使用 git rebase？

Question

為了實現 git 必殺技，我花了一天時間學習如何在我目前合並的情況下利用 rebase。

當運行我認為是 git 101 流（我在下面詳細說明）時，我必須在將更改推回原點時push --force 。

我不是唯一的人 - 我知道這是覆蓋地面（參見1 、 2 、 3 、 4 、 5 ），並且我理解為什么需要使用力的技術原因。 我的問題是——有很多（很多）博客文章贊美 rebase 以及它如何改變了他們的生活（請參閱1 、 2 、 3 、 4列出一些），但沒有一個提到push --force是他們流動的一部分。 然而，幾乎所有現有 stackoverflow 問題的答案都說“是的，如果你要變基，你必須使用push --force ”。

鑒於 rebase 擁護者的數量和宗教信仰，我不得不相信使用 'push --force' 不是 rebase 流程的固有部分，如果一個人經常不得不強迫他們推動，他們就做錯了。

push --force是一件壞事。

所以這是我的流程。 在沒有力量的情況下，我可以通過什么方式獲得相同的結果？

簡單示例

兩個分支：

• v1.0 - 一個發布分支，只包含補丁
• master - 下一個主要版本的所有內容。

我有一些補丁提交和下一個版本的一些提交。

我想將補丁合並到我的母版中，這樣它們就不會在下一個版本中丟失。 啟蒙前我只想：

git checkout master
git merge v1.0

但現在我正在嘗試

git checkout master
git rebase v1.0

所以現在我在這里：

的時間：

git push

沒有骰子。

Answer 1

Rebase 是一個很棒的工具，但是當您使用它為主題分支創建快進合並到 master 時，它的效果最佳。 例如，您可以針對 master 重新設置 add-new-widget 分支：

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

在執行分支到 master 的快進合並之前。 例如：

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

這樣做的好處是你的歷史不會有很多復雜的合並提交或合並沖突，因為你的所有更改都會在合並之前重新基於 master 的提示。 第二個好處是您已經重新定位，但您不必使用git push --force因為您沒有破壞 master 分支上的歷史記錄。

這當然不是 rebase 的唯一用例，也不是唯一的工作流程，但它是我見過的更明智的用途之一。 天啊。

Answer 2

@CodeGnome 是對的。 你不應該在 v1.0 分支上 rebase master，而應該在 master 上 rebase v1.0 分支，這會有所不同。

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

創建一個指向 v1.0 的新分支，將該新分支移動到 master 之上，然后將新版本的 V1.0 補丁集成到 master 分支。 你最終會得到類似的東西：

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

這種使用rebase的方式是git官方文檔推薦的。

我認為您對git push --force看法是正確的：只有在您犯了錯誤並推送了您不想要的內容時才應該使用它。

Answer 3

如果你變基了，你必須強制推送，而且你已經發布了你的更改，對嗎？

我使用了一大堆變基，但我要么發布到一些與強制推送無關的私有內容（例如：我自己在 GitHub 上的克隆，作為拉取請求的一部分），要么在我第一次推送之前變基。

這是使用 rebase 的工作流程的核心，但不要強制推送太多內容：在准備好之前不要發布內容，不要在推送后重新設置。

Answer 4

我認為這種 rebase-then-force-push 模式有一個很好的用例，它不是錯誤推送的結果：您自己從多個位置（計算機）處理功能分支。 我經常這樣做，因為我有時在辦公室使用台式機工作，有時在家里/客戶現場使用筆記本電腦工作。 我需要偶爾變基以跟上主分支和/或使合並更干凈，但是當我離開一台機器去另一台機器工作（我只是拉）時，我也需要強制推送。 只要我是唯一一個在分支上工作的人，它就像一種魅力。

Answer 5

這是我使用的（假設您的分支名稱是foob​​ar ）：

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

Answer 6

tl;dr 與共享分支合並，與單個分支合並。 --force-with-lease是一種更安全的強制替代方法，應該可以幫助您在沒有強制破壞性的情況下實現上述 git 必殺技。

我見過適用於各種團隊工作流程的一般經驗法則是對共享分支（即 master 或 develop）使用merge ，並在處理自己的功能分支時使用rebase 。 這是一個特性分支的典型生命周期

git checkout master
git checkout -b new-feature
git commit -am "commit new work"
git push -u origin new-feature
# have code reviewed, run CI, etc.,
# meanwhile master has new commits
git checkout master
git pull origin
git checkout new-feature
git rebase -i master # -i for interactive rebase allows you to squash intermediate commits
git push --force-with-lease
git merge master

我們在這里所做的事情的簡單英文版本：

1. 在 master 之外創建了一個新分支
2. 在分支上完成工作並推送到遠程
3. 重新基於主
4. 通過force-with-lease工作推送到遠程
5. 使用非常干凈的 git log 合並到 master，減少來自我們共享分支的多次合並造成的混亂，以使我們的分支“趕上”最新的 master（共享分支）

第四步非常重要，也是我開始提倡使用 rebase 的主要原因之一。 force-with-lease檢查遠程以查看是否添加了任何新提交。 如果你的git push被證明是破壞性的，它就不會推送！

我希望這能讓人們更有信心使用 rebase。