為什么拉取請求會在變基后顯示額外的提交？

Question

所以我從一個拉取請求開始，它是在develop之前提交的幾個提交，我們稱之為分支feature 。

feature與開發有 1 次合並沖突。 所以我決定重新設置它並解決沖突。

1. git checkout develop git pull
2. git checkout feature git pull
3. git rebase develop
4. 合並沖突已修復 - 添加了新提交
5. git rebase --continue
6. 變基成功。
7. git push （我實際上是在使用“同步更改”）

在這些步驟之后，gitHub 上的 PR 從 7 次提交變成了 60 多次提交。

我本來預計它只會從 7 次提交到 8 次提交，因為我修復了一個沖突。

關於發生了什么以及如何（如果需要）解決它的任何想法？

如果需要，我可以發布其他信息

---

編輯，這就是我遇到問題的原因：

仔細檢查您是否在控制台中使用git push --force而不是在 vscode 中使用git sync按鈕：

變基后從不同步

改用git push --force ！

Answer 1

查看您分支的 git log 並嘗試找出任何不尋常的地方。

使用git log提到了一條評論，但您也可以使用git log --graph --oneline來獲得分支提交歷史的可視化表示。 如果您的分支正確地重新設置了基礎，您會看到以下內容：

* 5eccc30d1 (HEAD -> feature, origin/feature) # Your commit message 8
* 5f73d262a # Your commit message 7
* 6c636b744 # Your commit message 6
* 97e17a7cf # ...
* 596297507 # ...
* 4646ce633 # ...
* 9fb61eb95 # ...
* 38dab17ae # Your commit message 1
*   7532142f7 (origin/develop) Merge pull request #...
|\
| * 042303c7e Add feature
* |   008f1e53b Merge pull request #...
|\ \
| * | 5a398f715 Fix issue with #...
# And so on

與此進行比較，並嘗試找出任何不尋常的地方。 你第一次提交下面的提交應該是你的基礎分支，並且你寫的那些中不應該有任何提交。

我懷疑在您的功能分支中使用git pull可能存在問題。 如果您自己正在處理此 PR，則沒有理由這樣做，並且因此可能會出現問題。

如果您需要使用功能分支進行拉取，請嘗試使用git pull --rebase代替，這相當於 fetch 和 rebase，而不是 fetch 和 merge。 這可以確保您的本地提交保持在您的歷史記錄之上，以防您的本地分支和您的來源之間存在差異。

Answer 2

問題可能是您的feature分支可能是從某個不同的分支簽出的，比如說test已經有很多提交了。 因此，即使您從要提出的同一分支重新建立基礎，您也會遇到提交不一致的情況。 我知道要解決這個問題，從開發分支創建一個新分支，然后從feature分支中挑選所有提交。

Answer 3

這是想法可能發生的事情。

當您繼續將提交添加到將被重新設置的分支時，可能會發生這種情況。 假設我們有兩個分支master和dev 。

master A-B-C
         |
dev      D-E-F

現在我們推送dev進行審查。
在等待審核的時候有新的任務。 分支dev獲得新的提交，所以本地看起來像：

dev A-B-D-E-F-G

注意這里沒有 C 提交在分支dev 。 之后，您的拉取請求被接受，並且您遠程（例如在 github 中）將您之前的更改重新設置為master ：

master A-B-C-D'-E'-F'

到那時，您已經有了復制 D'-E'-F' 提交的分支master ，該提交從 C 提交開始。 但是您的本地dev人員不同，沒有 D'-E'-F' 因為它有 DEF。 更重要的是它沒有 C 提交。

master A-B-C-D'-E'-F'
dev    A-B-D-E-F-G

現在你又想用 rebase 將提交 G 添加到 master 中。
兩個分支的共同部分是 AB。 因此，當您重新配置時，git 無法識別 D' 和 D 是相同的，因為它們從不同的點開始（對於dev來說它從 B 開始，對於master它從 C 開始）。 因此，在預覽新的拉取請求時，您不僅會看到提交 G，還會看到 DEF。

解決方案

快速獲勝是從實際master創建新分支，例如temp分支。
Cherry-pick 新提交到temp 。 要獲得提交的哈希數，只需在開發時嘗試git log --oneline 。

master A-B-C-D'-E'-F'
dev    A-B-D-E-F-G
temp   A-B-C-D'-E'-F'-G

temp分支包含master上存在的所有提交以及來自dev分支的新 G 提交。

[master] git checkout -b temp
[temp]   git cherry-pick 6e687f90 
[temp]   git checkout master
[master] git merge temp

其他可能的方法是在master上 rebase dev並解決所有沖突。 然后將請求從dev拉到master 。 如果dev上有很多重復的提交，這可能是一個痛苦的過程。