如何將遠程主分支轉換為本地開發分支？

Question

我想從master那里將更新帶入我的開發分支，我試圖做的是應用以下命令：

 git checkout master
 git pull
 git checkout develop
 git rebase master

通過執行以上命令，我得到以下警告：

首先，快退一下，重播您的作品...

另外，我不確定是否應該執行rebase還是從母帶merge到開發。 我在網上提到了幾篇文章，其中一篇建議為

重新確定基准是更改應如何從層次結構的頂部向下傳遞，而合並則是更改如何向上流動。 （ 鏈接 ）

並在Microsoft 文檔它暗示變基時（在實施例其表示衍合develop到master ）：

建議的方法是允許對您已進行但尚未與其他人共享的本地更改進行基礎計算，但是一旦與其他人共享更改就可以合並。 這避免了重寫歷史記錄的麻煩，同時仍使您可以在本地開發代碼時輕松趕上更改。

我想知道從master分支到開發分支進行最新更改的最佳方法。

Answer 1

以我的拙見，除非您是一個有信心的git用戶，否則git rebase (-i)會導致更多問題，而不是解決的問題。

請注意，例如， GitHub和Atlassian在其git flow教程中均未使用重定基。

當然，git flow只是一種方法，Atlassian在其Feature Branch Workflow文章中寫道：

一旦Bill准備好接受拉取請求，就需要有人將功能合並到穩定的項目中（這可以由Bill或Mary來完成）：

 git checkout master git pull git pull origin marys-feature git push 

此過程通常會導致合並提交。 一些開發人員喜歡這種方式，因為它就像該功能與其余代碼庫的符號連接。 但是，如果您偏向於線性歷史記錄，則可以在執行合並之前將特征重新設置到母版的頂端，從而實現快速合並。

我是合並提交的支持者，我鼓勵您不要使用重新定級。

Answer 2

首先，快退一下，重播您的作品...

那不是警告。 這是重新設置基准的正常輸出。 如果有警告，git會告訴您（ WARNING:就像您看到的CONFLICT: ）。

注意：快進rebase並不會做任何工作-不會合並，也不會倒退HEADS。 因此，即使您使用git rebase ，git也不輸出該行

至於在合並還是變基之間進行選擇，在大多數情況下都是慣例。 遵循您的團隊希望您使用的約定-如果他們主要將更改基於基礎，然后執行。

如果沒有約定，請按照您的直覺告訴您。 合並會根據時間保留提交的順序，清楚地顯示出發散和收斂，就像現實生活中發生的那樣。 Rebase使歷史記錄看起來無縫且整潔（通過編輯歷史記錄，因此為什么不應該對其他牽引的分支進行重新定位）。

我嘗試使用rebase。 我喜歡干凈的歷史記錄-這個人更改了ABC，然后又更改了XYZ。

Answer 3

我會避免變基。 如果您直接將一些承諾提交給大師（不是一個好主意），並且需要帶動他們發展-

git checkout develop
git merge master