我看過很多關于這個的帖子，但情況并不完全相同。
我在這里用我的例子做了一個存盤庫。
- 我創建了一個空倉庫和“開發”分支。
- 我用 lorem ipsum（“第一次提交”）創建了一個檔案。
- 我用 Asimov 資訊（“第二次提交”）替換檔案內容。
- 我將檔案內容替換為 Dan Simmons 資訊（“第三次提交”）。
- 我在“develop”和“master”之間創建了一個 PR，并使用了“rebase and merge”模式。
一切都很好。
- （仍在“開發”中）我將檔案內容替換為 Frank Herbert 資訊（“第四次提交”）。
- 我在“develop”和“master”之間創建了一個 PR，但遇到了沖突問題。
在第二個 PR中，您仍然可以看到“第二個”和“第三個”提交，即使它們已經在之前的 PR中。
根據第二次 PR 更改，該檔案包含 lorem ipsum（這是錯誤的，“master”上的檔案是關于 Dan Simmons 的），并將由 Frank Herbert 更新（這是正確的）。
我了解公關“變基和合并”不是“真正的”變基。它是每個提交的副本（實際上更像是一個櫻桃選擇）。但是Github不是能夠以更正確的方式處理它嗎？還是我的理解有誤？
我們不應該能夠在同一分支之間多次以“rebase and merge”模式進行 PR 嗎？
uj5u.com熱心網友回復：
如果分支（develop）保持原樣，那么合并的原始修訂并沒有真正合并......如果develop應該是長期存在的（就像您將它用于多個 PR 的情況）然后重寫歷史記錄（通過變基或擠壓）不是一種選擇。
假設你有這個：
A <- B <- C <- (develop)
^
\- (master)
當你合并時，你得到了這個：
A <- B <- C <- (develop)
^
\- B' <- C' <- (master)
注意怎么develop不動。如果您在 中添加新修訂develop：
A <- B <- C <- D <- (develop)
^
\- B' <- C' <- (master
如果您要求合并，git 將需要考慮來自 的更改A，而不是來自C或C'
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/531150.html
標籤：混帐github