具有多級分支深度並通過合併請求合併的Git和團隊資源管理器

我們使用TFS並且最近（在上個月內）切換到Git VC。我們制定了策略，因此不允許手動合併到主分支中。相反，我們有拉取請求的策略，只有在拉取請求獲得批准時才允許合併。具有多級分支深度並通過合併請求合併的Git和團隊資源管理器

我遇到以下情形：

創建的本地分支BranchA從master
開發完成上BranchA，從BranchA打開相對於master
拉入請求創建的本地分支BranchB，如BranchB依賴BranchA中的代碼
完成開發BranchB，拉動請求相對於打開BranchA

我理解的Git沒有引入請求的概念，嚴格來說，合併分支機構一起不構成真正的關心。那就是：

BranchB合併BranchA合併master僅僅是因爲這樣做 BranchB合併master細，然後BranchA合併master

我掙扎辨別清晰的方式來拉時進行合併涉及請求。我所做的是：

爲BranchB完全拉入請求其合併到BranchBBranchA
完全拉請求BranchA其合併到BranchAmaster

不幸的是，這種做法引起BranchA的pull請求將被更新爲來自BranchB的最新更改，這些更改膨脹了請求並取消了它的原始意圖（因爲現在有更多文件需要查看）。

如果我切換訂單，那麼BranchA拉請求完成後，我必須確保遠程分支不會被刪除，因爲BranchB依賴於它的存在（這是一個假設，也許TFS將拉請求從物理分支？）。

如果我讓BranchB的拉動要求相對master，然後拉請求將包括BranchA和BranchB變化，因爲master不知道的還BranchA。

我正在尋找任何有關如何處理這種情況的建議，而不會膨脹拉請求。

來源

2017-02-24 Sam

你可以在你的第二個場景中刪除分支就好了，分支不是特定提交上的「標籤」。只要還有其他提交仍然引用這些提交，它們就不會消失。你怎麼能加快合併過程，所以BranchB可以開始主人？ – jessehouwing

啊，這是一個非常好的點，我記得很重要，分支只是標籤，提交是真正的交易。所以在這種情況下順序並不重要，'BranchA'可以先合併。至於加速合併，這是一個讓團隊其他成員完成審查和批准代碼的問題（我們的合併策略在合併發生之前需要兩個批准者）。理想情況下，這些拉動要求是短暫的，但情況並非總是如此。另外，我通常會在打開「BranchA」的拉取請求之後立即準備好在「BranchB」上啓動開發 – Sam

A pull request是fetch後跟merge。就像你在評論中說的分支只是標籤一樣，提交是真正的交易。

對於您的案例，解決方法可能會合並兩個分支中的拉請求。例如，直接從BranchB相對於master創建拉請求。拉取請求被接受後。至今在BranchA合併它你可以簡單地做在您的本地回購：git checkout的BranchA，git merge與BranchB（或提交你試圖用merge），然後git push當地BranchA分支到遠程回購的BranchA分支。

git checkout Branch A 
git merge Branch B 
git push origin Branch B

來源

2017-02-27 10:21:30

具有多級分支深度並通過合併請求合併的Git和團隊資源管理器

回答

相關問題