合并拉取請求時，可能存在需要在合并之前解決的沖突。
基本上，有2種方式：
- 重定位于頂部解決沖突
- 拉取目標分支并解決沖突
pull 方法會在合并之前在分支中產生一個額外的合并提交（解決沖突），我不希望這樣：
正如所見，分支有一個包含與更改相關的內容。我希望分支的歷史記錄僅包含相關更改。
node Bnode A
如果我進行 rebase，分支的歷史記錄將確實只包含相關的更改。盡管如果node B的更改依賴于node C.
內部的變化node B和node C邏輯上是相互獨立的。他們直接修改node A.
這是一個檔案node A：
first line: text node A
second line to be removed later
third line: text node A
node C 只修改第一行和第三行：
first line: node C text
second line to be removed later
third line: node C text
node B 只洗掉第二行：
first line: text node A
third line: text node A
雖然從邏輯上講，我在這里沒有看到任何沖突（來自兩個節點的更改會修改不同的行），但是 git 將無法自動解決沖突。
- 我可以解決初始拉取請求的合并提交中的更改嗎？
- 此類沖突能否首先自動解決？
- 當更改影響不同的行時，為什么 git 會看到沖突？
我想在發布之間盡可能保持 git 歷史記錄。觀察者應該清楚哪些變化是相互依賴的，哪些不是。將獨立更改直接應用于“基礎”（發布提交）node A有助于最大程度地減少主分支的突變。
uj5u.com熱心網友回復：
你的三個問題最好分成至少兩個單獨的 StackOverflow 問題，但讓我們試試這個：
- 我可以解決初始拉取請求的合并提交中的更改嗎？
Git 本身沒有“拉取請求”，因為 GitHub 或 Bitbucket 有拉取請求。Git 只有commits，擁有 Git 存盤庫的個人可以獲得和/或進行新的提交，包括合并提交，使用git fetch和 等命令git merge，當組合成單個命令列命令時，可以拼寫為git pull。該git request-pull命令生成一封電子郵件，然后您可以使用任何電子郵件發送程式發送該電子郵件，要求其他人“拉”一些提交。
由于 Git 一開始就缺乏這些型別的拉取請求，因此簡短的回答是“不”。如果我們查看 GitHub 和 Bitbucket 等站點，答案取決于托管站點。據我所知，GitHub 的當前答案仍然是“否”，盡管如果他們有一個功能可以提供建議的最終合并提交，那可能會很好。1 我還沒有充分使用 Bitbucket，以至于我什至可以推測他們的情況。
- 此類沖突能否首先自動解決？
不（但見下文）。
- 當更改影響不同的行時，為什么 git 會看到沖突？
要組合的兩個變化鄰接（在邊緣處接觸）。確實存在不將這些視為沖突的合并演算法，但經驗表明結果經常被破壞。因此，確實將這些視為沖突的合并演算法是使用的演算法（這就是問題 2 的答案的原因）。
當不使用像 GitHub 這樣的托管站點時，這里的通常程式（根據我的經驗）是直接合并到目標分支，解決那里的沖突，然后提交。結果樹（源快照）與通過從目標分支合并到創建 PR 的分支中獲得的樹相同，但沒有額外的合并提交。
1這在技術上是可行的，但我不知道 GitHub 如何將其連接為用戶可訪問的界面。當您生成 GitHub PR 時，GitHub 將在內部：
- 運行
git merge以查看自動合并是否有效。 - 如果是，則生成兩個標簽，和，指向要合并的提交和測驗合并的結果。
refs/pull/n/headrefs/pull/n/merge - 如果不是，則生成一個標簽，指向要合并的提交。測驗合并結果似乎被丟棄。
refs/pull/n/head
添加提供提議的合并解決方案的第三個標簽，以及由制作 PR 的人提供的提交，可能是合理的。完整的細節將取決于托管站點，但沒有明顯的外部原因甚至不能使用標簽。refs/pull/n/merge
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/338545.html