我们应该多久查看一次git中的功能？
在我们的团队，目前，我们应该多久查看一次git中的功能？
- 我检查代码，并将其合并到开发分支每当有人完成一个功能。
- 他开始工作之前等我回顾一下。
- 我审查并批准后，他从开发中为下一个功能创建一个新分支并开始工作。
在这个工作流程中，问题是，我总是感到不安。我的工作滞后，因为有时我必须每天审查和合并很多次。
我们该如何解决？从第一个功能分支到第二个功能的工作是否安全无需在每天结束时进行合并和审查？什么是最好的工作流程？
与其让开发人员围着他们的拇指坐着，他们可以前进并承担风险;如果前一个功能出现小问题，请修复它并将第二个分支重新绑定到它上面。如果存在重大问题，第二个分支必须报废，那就是风险。
但是真的应该有开发人员可以做的任何数量的任务，这并不取决于他们以前的分支。有一个分支直接依赖另一个分支应该是相当罕见的。如果这很常见，那么您需要认真研究如何定义“功能”。这些功能可能太宽泛，并且会触及太多的代码。或者他们可能太小而未完成。该代码可能需要重新构建以具有隔离的子系统。
然后有一个人（你）正在做所有的审查的问题。你的过程有一个瓶颈，你就是它。其他人必须被允许进行评论。这将缓解过程瓶颈。你可以做其他事情。你的团队将拥有更多的工作。你将能够休假，而不会让所有工作停下来。你的团队将学会更加自力更生。
总结...
- 允许更多人做评论。
- 避免使用功能直接取决于其他功能。
这里有一些指针，希望它有助于
你的评论的代码，但我认为合并的分支应该是谁创造了它的开发者的责任，这将节省您的时间。
我不明白为什么开发人员应该等待您批准并合并它的第一个分支。除了他的下一个特征直接取决于第一个特征的情况，他可以简单地从主人（开发分支）重新分支开始处理他的下一个特征。
在我的团队的流程如下：
我开始通过创建一个新的分支feat_x上特征量x工作。一旦我的功能完成，我创建一个Pull Request并添加2-3个开发人员作为审阅者。在审查过程中，我开始以同样的方式处理功能y。当我的合并请求获得批准时，我将它合并并开始构建。
您所描述的问题在软件工程中是不可避免的。从'feature'分支开始第二个功能是有风险的，因为第一个功能可能有问题，然后在分支的时候继承。您应该创建一个工作流，让多位工程师可以并行处理任务。如果这不能完成，那么你只需要等待一些事情完成。 –
他为什么需要等待？他可以继续他的其他工作。如果他后来的工作依赖于他以前未经证实的工作，那就好了。如果在审查期间发现任何问题，他可以更新他的代码，并重新组织他自己的分支。当我看到“merge”这个词时，它仅仅意味着应用一个补丁。我们可以使用'git merge'，'git rebase'，'git cherry-pick'，'git am'，'git apply'来执行'merge'。作为代码集成商，我不关心他们的分支是什么样的。没关系，只要我可以通过他们的补丁或提交或分支或回购甚至文字来获得适当的更改。 – ElpieKay