适合我们需要的最佳Git工作流
适合我们需要的最佳Git工作流
提问于 2014-09-20 17:35:38
我需要帮助的工作流，是最适合我们的需要。我们是一个3-4人的团队，正在进行4个不同的项目。
我们有三个主要分支：
- 主可展生产分公司
- 分阶段-在实时数据质量保证下的特性
- 开发- QA下的测试数据特性
然后，我们为每个特性创建一个功能分支。
我们需要的是：
- 有时，我们希望创建一个发行版(针对许多有共同之处的特性)，并在月底部署。
- 有时，我们希望部署一个特定的特性/更改(而不是创建一个版本)。我们大部分时间都是这样做的。
现在转到工作流：
- 我开始研究一些特性。我从dev创建了一个特性分支。
- 我完成了我的特性(用30次提交)。
- 我把我的特性合并到dev中，所以它只是一个提交。
- 这个特性会自动部署到测试环境中，QA会对测试数据测试我的特性。
- 这个特性测试正常，所以我选择我的特性提交散列到一个暂存分支。这个特性会自动部署到一个暂存环境中，QA会在实时数据上测试我的特性。
- 这个特性通过了QA (测试和分期)，要么被精心挑选成主版本，要么通过发布分支，后者将在本月底与master合并。
这里有一张图片解释了我的想法：
这一切都有意义吗？是否有更好的方法来实现这一目标？耽误您时间，实在对不起。
回答 2
Software Engineering用户
发布于 2014-09-20 19:24:00
看上去很合理。我们使用的是非常相似的东西。我的建议是将功能分支保持小。也许有一天工作。较长的支撑意味着由于大量合并冲突而降低生产率。大多数情况下，一个特性分支等于我们scrum板上的一个帖子。
请注意，您可以写“我开始处理某个特性，我从dev创建了一个特性分支。”这是一个很好的方法，80%的时间。请记住，您可以选择将挂起的拉请求分支。我们有一个关于团队的规则，我们应该让团队中的其他人来检查和合并拉请求。有时PRs会在队列中停留几个小时。因为我们使用的是非常小的拉请求。有时候特性B依赖于特性A，但是功能A在几个小时内不会被合并，因此不会在dev中合并。当您想要开始处理功能B时，只需从A中合并，而不是dev。如果可能的话，最好合并off，但是它是一个很好的工具。在这种情况下，在功能A合并为dev之前，您可能应该等待为feature创建PR，因为diffs看起来像两个A+B，这是误导性的。
Software Engineering用户
发布于 2014-09-27 18:07:29
因为我们必须在测试和暂存环境中部署特定的特性，所以我在考虑这样的事情：
两个主要分支：
- 主控
- dev
- 特性分支是从dev中分支的。
- 当一个特性准备好进行测试时，我们会添加一个标记测试/发布-1234。
- TeamCity注意到标记并部署到测试环境中。
- 当该特性通过测试时，我们将添加一个标记暂存/发布-1234。
- TeamCity注意到标记并部署到暂存环境中。
- 当该特性通过暂存时，我们向dev分支发出拉请求，然后有人检查代码和逻辑。
- 如果代码评审进行得很好，他会将分支合并到dev中。
- 按月计算，我们将dev分支合并为master。
这听起来怎么样？
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://softwareengineering.stackexchange.com/questions/256811
复制相关文章
相似问题
腾讯云开发者
