如何推/拉Git rebase

Question

我想使用git rebase以便干凈地合並主分支中的一個功能（在較少的提交中或至少在更改日志的頂部）。 請注意， 我是唯一一個在存儲庫上工作的人 。

看完后Git的工作流程和重訂VS合並的問題 ，我發現git rebase會很不錯，像米卡我想git push ，只是因為我對他們的工作從不同的地方重訂基期的變化（例如：我的筆記本，我的家，另一台電腦......）

所以這里有兩個解決方案（對於雙向難看的合並）：

1. 使用git push -f推送，然后拉動其他機器，但如何在其他機器上干凈利落地獲取最新版本？
2. 使用merge將主更改合並到功能分支，git push / pull，並且一旦成熟，就執行一個rebase（在一個或多個提交中干凈利落）

（2）如下所示：

git co -b feature-a
... change files
git push origin feature-a
... moving to another PC
git pull origin feature-a
... change files
git merge master
... change files (not the "special rebase")
git rebase master
git co master
git merge feature-a
git branch -d feature-a
git push origin :feature-a

您認為哪種解決方案有效？ 到目前為止，我還沒有嘗試過其中任何一種（主要是因為害怕讓我的日志變得更加混亂）。

Answer 1

我總是確保我提交並推送（-f）我離開的任何機器上的所有內容。

當我到達其他機器時：

 git fetch -v
 git checkout mybranch # Already checked out with old HEAD
 git reset --hard origin/mybranch

這很有效，因為我知道在我離開之前，不同計算機上的其他“我”一直在提交和推送（因此我到達的機器上沒有未按下的更改）

Answer 2

請記住， git rebase重放更改並創建新的提交。 通過重新定位和強制推動整個地方，你將違背工具的粒度。 請注意git rebase文檔中的“從上游rebase恢復”部分是如何開始的（更加強調）：

重新定位（或任何其他形式的重寫）其他人基於其工作的分支是一個壞主意：它下游的任何人都被迫手動修復其歷史記錄。 本節介紹如何從下游的角度進行修復。 然而，真正的解決方法是首先避免重新定位上游。

即使您是唯一的開發人員，在其他克隆中工作時，您仍然會成為其他人（從一個回購的角度來看）。 如您所見，這個工作流程很麻煩。

讓你的變化在分支中烹飪。 當分支准備好進入黃金時段時， 然后重新綁定，將其合並到主服務器中，並刪除其主題分支。 如果你讓分支的壽命縮短，范圍縮小，你的生活將變得最簡單。