會合並--squash會導致已經在開發中的cherry picks發生衝突

我們正在使用git流模型合併功能分支，通過pull請求將它們重新分支到開發分支中。會合並--squash會導致已經在開發中的cherry picks發生衝突

有時一個特徵分支櫻桃從另一個分支挑選，其中一個將首先合併到開發中。當第二個人重新開發時，那些櫻桃鎬很快被轉發。

我的問題：currenty我們只是使用合併（這可以很容易地替換爲 - 我只是假設我們總是變基），但我們也可以 - 只是--squash - 只是？那麼當櫻桃採摘的承諾在這些承諾已經在那裏時被重新開發到開發中時，這會引起衝突嗎？

我擔心會出現額外衝突的原因如下：假設commit1和commit2都在一個文件中進行更改。如果他們被合併到開發中，然後櫻桃選擇他們的第二個分支進行了rebase，它會認識到這兩個提交已經在那裏。

如果這兩個提交被壓縮並且試圖在其上重新綁定，它將不會再看到，並且在重新綁定頂部的第一次提交時已經包含commit2並因此導致衝突。

feat1: ... A -- B 
feat2 ... A (cherry picked) -- B (cherry picked)

FEAT1與擠進合併開發

develop .... S

會重訂FEAT2到發展產生矛盾，如果A和B編輯同一個文件？

2017-07-07 Nickpick

絕對壓扁提交會阻止修補程序ID檢測，所以再版軟件不再能夠保護您免受櫻桃採摘提交的衝突。（反之，如果提交序列製作和恢復的變化，那麼潛在的衝突可以通過擠壓被淘汰 - 但是這更多的除外）

2017-07-07 13:17:04

大概不會令採摘櫻桃不可能的，當合並是一個重訂之前壓扁，除非一個功能分支它也會被壓扁？ – Nickpick

不可能嗎？不，更難？是。擠壓「另一面」並沒有幫助，因爲你最終還是會得到兩個提交（a）不會產生完全相同的補丁，但（b）會影響某些文件的相同行。挑選櫻桃之後唯一能防止衝突的方法就是如果櫻桃挑選前和挑選後的挑戰保持「不平衡」 –

順便提一下，我應該指出，基地似乎有一些額外的魔術，可能會自動解決一些即使在打壁球之後也會從櫻桃採摘中產生的一些衝突。你失去的是「第一道防線」：當雙方都有一個承諾轉化爲*完全相同的補丁*時，你可以肯定會避免產生的衝突 –

回答