我們應該多久查看一次git中的功能？

我檢查代碼，並將其合併到開發分支每當有人完成一個功能。
他開始工作之前等我回顧一下。
我審查並批准後，他從開發中爲下一個功能創建一個新分支並開始工作。

在這個工作流程中，問題是，我總是感到不安。我的工作滯後，因爲有時我必須每天審查和合並很多次。

我們該如何解決？從第一個功能分支到第二個功能的工作是否安全無需在每天結束時進行合併和審查？什麼是最好的工作流程？

2016-06-01 THpubs

您所描述的問題在軟件工程中是不可避免的。從'feature'分支開始第二個功能是有風險的，因爲第一個功能可能有問題，然後在分支的時候繼承。您應該創建一個工作流，讓多位工程師可以並行處理任務。如果這不能完成，那麼你只需要等待一些事情完成。 –

他爲什麼需要等待？他可以繼續他的其他工作。如果他後來的工作依賴於他以前未經證實的工作，那就好了。如果在審查期間發現任何問題，他可以更新他的代碼，並重新組織他自己的分支。當我看到「merge」這個詞時，它僅僅意味着應用一個補丁。我們可以使用'git merge'，'git rebase'，'git cherry-pick'，'git am'，'git apply'來執行'merge'。作爲代碼集成商，我不關心他們的分支是什麼樣的。沒關係，只要我可以通過他們的補丁或提交或分支或回購甚至文字來獲得適當的更改。 – ElpieKay

與其讓開發人員圍着他們的拇指坐着，他們可以前進並承擔風險;如果前一個功能出現小問題，請修復它並將第二個分支重新綁定到它上面。如果存在重大問題，第二個分支必須報廢，那就是風險。

但是真的應該有開發人員可以做的任何數量的任務，這並不取決於他們以前的分支。有一個分支直接依賴另一個分支應該是相當罕見的。如果這很常見，那麼您需要認真研究如何定義「功能」。這些功能可能太寬泛，並且會觸及太多的代碼。或者他們可能太小而未完成。該代碼可能需要重新構建以具有隔離的子系統。

然後有一個人（你）正在做所有的審查的問題。你的過程有一個瓶頸，你就是它。其他人必須被允許進行評論。這將緩解過程瓶頸。你可以做其他事情。你的團隊將擁有更多的工作。你將能夠休假，而不會讓所有工作停下來。你的團隊將學會更加自力更生。

總結...

允許更多人做評論。
避免使用功能直接取決於其他功能。

來源

2016-06-01 06:05:32 Schwern

這裏有一些指針，希望它有助於

你的評論的代碼，但我認爲合併的分支應該是誰創造了它的開發者的責任，這將節省您的時間。
我不明白爲什麼開發人員應該等待您批准併合並它的第一個分支。除了他的下一個特徵直接取決於第一個特徵的情況，他可以簡單地從主人（開發分支）重新分支開始處理他的下一個特徵。

在我的團隊的流程如下：

我開始通過創建一個新的分支feat_x上特徵量x工作。一旦我的功能完成，我創建一個Pull Request並添加2-3個開發人員作爲審閱者。在審查過程中，我開始以同樣的方式處理功能y。當我的合併請求獲得批准時，我將它合併並開始構建。

來源

2016-06-01 05:08:42

我們應該多久查看一次git中的功能？

回答

相關問題