在推送之前管理從開發分支到功能的更改（git）

Question

我過去工作過的大多數團隊在使用 Git 時都遵循相同的工作流程（有一些微小的變化）：

1. 拉取develop分支（ git checkout develop ）
2. 創建一個新的功能分支（ git checkout -b feature/XYZ-123 ）
3. 做你的工作
4. When you are ready to create a PR, add and commit your changes ( git add. && git commit -m "some commit message" ), then check develop back out, pull it ( git checkout develop && git pull )
5. 切換回您的功能分支並將develop合並到其中（ git checkout feature/XYZ-123 && git merge develop ）
6. 最后推送（ git push -u origin feature/XYZ-123 ）並創建一個 PR

我們將其稱為“合並方法”。 好處是，自從您創建分支以來要develop的任何更改現在都合並到您的分支中。 因此，當您創建 PR 時，與develop沒有合並沖突，代碼審查者可以看到您的分支和develop之間的干凈、無沖突的差異。

我現在正在一個團隊工作，該團隊在合並步驟之前具有類似的流程，但是他們沒有將develop合並到我的功能分支中，而是要求從origin/develop進行變基。 所以實際的步驟是：

1. git checkout develop
2. git checkout -b feature/XYZ-123
3. 做你的工作
4. git add. && git commit -m "some commit message"
5. git checkout develop && git pull
6. git checkout feature/XYZ-123
7. 從origin/dev變基
8. git push -u origin feature/XYZ-123

我們將其稱為“變基方法”。 它也產生了無合並沖突的 PR，但顯然它必須與上面解釋的合並方法有不同的優點/缺點。

我想知道這些優點/缺點是什么。 Merge 方法在 Rebase 方法中缺乏什么，反之亦然？ 什么時候應該使用一種方法而不是另一種方法？

Answer 1

但顯然它必須與上面解釋的合並方法有不同的優點/缺點

並不真地。 在反向合並（我稱之為）和變基之間，最終效果完全相同，即嘗試從develop中獲取所有最新更改，以便（1）可以准確測試功能分支和（2）減少合並到develop時發生合並沖突的機會。

反向合並和變基之間的主要明顯區別是功能分支上缺少額外的合並提交。 這使得 rebase 很有吸引力。 所以：

• 變基在歷史上看起來要干凈得多，因為您似乎已經從更近的 state 的develop開始了分支。

但這里有一些反訴：

• 如果有即將到來的沖突，變基會使解決這些沖突變得更加困難。

• 推送形成拉取請求后，您不能變基，因為這會重寫共享歷史； 而您可以隨時反向合並。

我個人兩者都用； 我在初始推送之前重新設置拉取請求，如果拉取請求存在很長時間，我會定期反向合並。 尤其是在實際批准和合並之前。