'Squash and Merge' 是 Pull 請求合并的選項之一，與可以通過git rebase -i選項完成的'Squash and Rebase' 之間有什么區別？
為什么人們推薦“Squash and Rebase”而“Squash and Merge”存在？
我正在嘗試使用 git 作業流程。以前我使用 rebase 將提交從功能分支合并到開發分支。這使得開發分支整潔，并且可以洗掉合并的功能分支。
但是，如果 feature 分支中的 commit 太多，則存在一個問題，即 develop 分支變得太長。所以我嘗試在合并功能分支的同時壓縮提交。
然后我發現 git hub 提供了“Squash and Merge”，但也有人推薦“Squash and Rebase”。
我已經嘗試了這兩種方法，除了“Squash and Rebase”提交包含所有提交訊息而“Squash and Merge”沒有的其他提交訊息之外，它沒有任何區別。
uj5u.com熱心網友回復：
我認為這是為了避免出現臟樹，就好像在與主分支合并之前沒有 rebase 一樣。而且你有多個分支，它很快就會看起來像這樣：
你會同意我的觀點，很難看到發生了什么。
在合并之前使用 rebase，它看起來會更干凈，也更容易理解：
uj5u.com熱心網友回復：
這不是純化妝品。做 rebase 允許將沖突解決到提交本身，而沒有 rebase，由于沖突，合并提交可能包含一些差異。
無需重新定位，您就可以從分支開始的位置進行跟蹤，并可以跟蹤交付時間或其他事情。注意：這不是“擠壓和合并”，而是Rebase and Merge
使用視覺更容易：
允許合并提交使用合并提交將所有提交從頭分支添加到基本分支。
將來自 head 分支的所有提交合并到 base 分支中的單個提交中。
允許
合并提交
2021-09-02 17:05 0200 John doe M─│─┐ Merge branch 'bug51' into 'release'
2021-09-02 16:51 0200 John doe │ │ o Fix stupid bug
2021-09-02 16:42 0200 John doe │ │ o Try to fix
2021-09-02 15:50 0200 John doe M─│─│─┐ Merge branch 'featcool' into 'release'
2021-08-20 12:05 0200 John doe │ │ │ o Add a new cool feature
2021-08-20 10:47 0200 John doe │ │ │ o WIP cool feature
2021-09-02 15:22 0200 John doe M─│─│─┤ Merge branch 'feat2' into 'release'
2021-09-02 14:56 0200 John doe │ │ │ o chore: feat2
2021-09-02 10:16 0200 John doe M─│─│─│─┐ Merge branch 'feat1' into 'release'
2021-08-31 18:28 0200 John doe │ │ │ │ o feature so nice
變基合并
2021-09-02 16:51 0200 John doe o Fix stupid bug
2021-09-02 16:42 0200 John doe o Try to fix
2021-08-20 12:05 0200 John doe o Add a new cool feature
2021-08-20 10:47 0200 John doe o WIP cool feature
2021-09-02 14:56 0200 John doe o chore: feat2
2021-08-31 18:28 0200 John doe o feature so nice
壁球合并
2021-09-02 16:51 0200 John doe o Fix stupid bug
2021-08-20 12:05 0200 John doe o Add a new cool feature
2021-09-02 14:56 0200 John doe o chore: feat2
2021-08-31 18:28 0200 John doe o feature so nice
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/336619.html
標籤：混帐 github git合并 git-rebase
下一篇：貓鼬只更新不為空的欄位？