好的策略處理順序拉取請求之間的依賴關係

Bob克隆項目並從master創建本地分支A。好的策略處理順序拉取請求之間的依賴關係

鮑勃增加了一些有用的幫助類清理/重構單元測試設置，並清除所有現有的測試感謝他們。

Bob提交，推送到遠程服務器，然後創建一個拉請求，以便從John獲得對此重構的代碼審查。

約翰領導這個項目，忙於一個星期，所以無法立即審查。

要求代碼審查後，Bob想編寫一些全新的測試文件和設置的，因爲它被認爲是一個新的功能與工作相互分開拉請求結束補課。
顯然，鮑勃想用他的新助手來做這些測試文件。

哪種策略採用：

對於那些新的單元測試，鮑勃應該創建一個B分支從master派生，而不是A因爲A還沒有被任何評價。缺點是他不能使用他的單元測試助手，因爲B中不存在。
Bob應該等待第一個拉取請求的代碼審查，合併到master，然後從master導出B。在此期間，他應該關注其他不依賴於他之前的拉動要求的作品。
Bob應從A派生B並使用這些幫助者，並承擔A在審覈後不被接受的風險。顯然導致拒絕B。
約翰應該動搖他的屁股，作爲一個優秀的領導者，應當審查在很短的時間拉頭請求，以致鮑勃可以鏈接。

什麼是一個好的做法來處理系列中的多個請求之間的依賴關係？

來源

2017-01-31 Mik378

這是不必要的依賴和等待以前的你拉電流要求（PR）。對於您的情況，Bob希望在處理PR（已發佈且尚未批准）後繼續開發/測試基於分支A的內容。他只需要開發分支A上的代碼，然後將&推送到遠程。將分支A併入主設備的PR將自動包含Bob的第二次更改。

所以對於多PR的情況下，如果要更新它已經在拉請求分支，你只需要提交&推的變化，以前的PR可以自動更新。 如果你要更新的分支，它是不包含在處理公關，則需要提交&推的更改，然後創建一個新的PR，以及它對先前處理PR沒有影響。

如果你只是想添加一些微小的變化或者功能本身，則需要對分支A轉換，並使用處理公關。如果您需要開發新功能，則應對新功能分支進行更改並創建新的PR。

Bob的條件下，開發新的功能，並需要在分支A使用的助手，所以他應該從A甚至A獲得分支B尚未審查。由於開發人員需要考慮如何開發新功能，並且在先前的PR獲得批准之前開發新功能效率不高。或者如果你的團隊真的需要這樣使用，你仍然可以從A得到B，並且可以根據你的需要重新設置分支B.

來源

2017-02-01 01:46:08

我完全同意，我會像我這樣的團隊工作。「hic」是我在24小時前與一位技術領導接近的討論，他告訴我：「不......如果公關更新，不相關文件的數量（」功能「混合）將會增長而且我很可能一次執行一次整體代碼審查（同時修改/添加的文件太多）......所以我建議他們編寫第二個完全獨立的請求「。這可能是一個很好的做法，這就是爲什麼我有點困惑並寫了這篇文章。 – Mik378

我更新了關於第二個拉取請求內容的一些細節。 – Mik378

是的，你可以從你需要的分支派生一個新的分支，並創建一個新的PR。我更新了答案。 –

好的策略處理順序拉取請求之間的依賴關係

回答

相關問題