Perforce和功能分支

在我們公司，我們使用Perforce進行源代碼管理和版本管理。目前我們使用以下「樹」實現功能分支：Perforce和功能分支

Hotfix01 - Hotfix branch 
    Hotfix02 - Hotfix branch 
    HotfixNN - Hotfix branch 
Main (continuous trunk)  
    RC - Release Candidate branch (next release) 
    Working01 - Working branch, feature branch. 
    Working02 - Working branch, feature branch. 
    Working03 - Working branch, feature branch. 
    WorkingNN - Working branch, feature branch.

我們提前設置了分支。並不是說這真的很重要。 RC分支是功能分支。現在我們有50多個開發人員，分析師和QA團隊成員，他們單獨或作爲一個團隊在各種項目中工作，缺陷修復等等。當工作進入時，您會找到一個免費的分支（我們分別跟蹤），聲稱分支例如Working56），從RC到該分支做一個強制合併/同步（以確保它正是RC中的內容），做你的工作（代碼，同行評議，QA），同時不斷地將RC的任何改變合併到你的工作中分支（每天至少一次，也許更多的時候是根據需要），當你完成時，你將這些改變複製到RC。

這個工作，但它意味着我們有（在這個時候）300個工作分支來管理。我們希望以更加理智的方式實現功能分支，我們將使用分支映射來創建分支，並根據需要創建分支，然後將其合併回RC，然後我們希望它不再顯示在分支中永久的倉庫（至少，不是每個開發商）。基本上我們只想看到那些積極發展的分支作爲功能分支，隱藏我們完成的分支。

最佳做法是什麼？這可以通過使用分支或流的perforce來完成嗎？我們是否錯過了支持分支規範的東西？我們是否應該放心，讓數以萬計的特色分支堆積在RC的倉庫視圖中？我們現在做的方式是我們所希望的最好的方式嗎？

我們已經使用Perforce 10年了，這仍然是一個每天都在困擾着我們的問題。

來源

2017-05-30 Brian Mueller

目前尚不清楚多次開發多個開發人員在同一個功能部件上進行協作，但您可能會研究的一件事是Perforce DVCS功能。如果開發人員在他們自己的DVCS回購站中創建自己的分支機構，他們不會污染共享服務器，而分支機構只是暫時的。 –

在開發團隊中有很多個人和團隊合作的工作。我會使用這樣的期望，即任何工作單元可能需要至少3人（甚至只是一個bug修復 - 開發人員，同行評審，質量保證）才能被合併到任何父分支中。除此之外，任何規模的許多項目都有多個開發人員協作。 –

任務流是爲此設計的。

https://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html

創建任務流，做你的工作吧，合併/複製回父，然後unload任務流。

共同任務流陷阱：

不要試圖重複使用或重新設置父級它們。每個任務一個流！如果您嘗試重用任務流，他們的有益功能通常不起作用，但您仍然可以獲得所有的限制。
卸載任務流後，修改的depot文件將保持運行狀態。調整您的心智模型，將流列表用作流活動的真實源，而不是軟件倉庫樹中的文件夾。

如果你可以處理這些，任務流非常有用。

來源

2017-05-30 23:21:33

我對Streams的理解有限，就是它們分支在分支之上（Perforce將它們描述爲分支與腦）。創建一個流是否也會創建一個將駐留在庫中的分支，或者是否隱藏了這個分支，以便一旦流完成時不會混淆接口？我在文檔中沒有看到任何二進制文件，很遺憾，我無法快速設置測試環境，而我們當前的Perforce服務器版本不支持流。 –

我不認爲我可以在評論的空間中完整地解釋關於流的所有內容，但是你所說的是我所描述的「gotcha＃2」。獲得流的好處需要稍微調整一下你的工作流程，而且我通常建議如果你使用流，你不使用界面的倉庫選項卡部分，因爲它避免了流提供的倉庫的簡化視圖。 –

Perforce和功能分支

回答

相關問題