试图了解/确定基本的Git工作流程

Question

我已经一遍又一遍地阅读此popular document，以尝试草拟自己的git工作流程。

我想我已经做好了，但我仍然有些失落。这是我目前的理解...

我们有两个分支，它们将始终保持活动状态。

• 主：在这里，我将推送实际部署到生产服务器并供用户使用的代码。
• 开发：这将从master分支分支。它将包含我的所有新功能，错误修复等，这些功能将推送到下一个版本中。

我们有多个主题分支，它们将从开发分支中分支出来（我认为）。一旦确定了主题（例如错误），我们将将该分支合并回development分支。一些例子：

• 主题分支1：功能-ajaxify-购物车
• 主题分支2：bugfix-navbar-font-overlapping

准备发布

• 我们一次有1个发布分支，将从 功能分支。
• 现在，我们提取/合并所有功能，错误修复等，我们 希望推出下一个版本。
• 我们可以保留一些我们一直在努力的功能，这些功能将不会在下一版本中发布。

创建发行版

• 对发行版满意后，我们便可以将该发行版分支合并到master分支中，并将提交命名为“ v1.2.0”。
• 我们还想用'v1.2.0'标记提交，以便我们可以轻松地回到过去并查看发布。

我学到的笔记

master分支总是非常干净，仅包含作为发布的提交（我认为这就是为什么我们有一个单独的release分支，对吧？）。

请让我知道我在哪里弄乱了或误解了某些内容。谢谢！

Answer 1

您的摘要准确无误：您可以找到插图in this cheatsheet。

请注意，为了与其他功能一起测试您必须将它们合并以开发（git flow feature finish MYFEATURE）。
还有另一个工作流程（Git workflow）可以更好地促进功能（开发然后发布）

区别是：

• 通过git flow，多个feature分支在devel中合并（它们发现它们是否可以一起工作），然后从release创建devel（在这种情况下，删除功能变得很复杂），然后再合并回devel（和master）。
• 使用gitworkflow ：
  • feature分支被合并到一个“ public”“ alpha”分支，该分支在每次发行后重置（意味着在新发行版的顶部删除/重新创建）
  然后，将那些相同的feature分支的子集合并到“ next”（“ beta”）分支，以进行集成/接受测试。每次发布新版本后，都会在next顶部重新创建“ master”（“ beta”）分支。
  • 然后将feature个分支的子子集合并到master，以准备下一个版本。

“ public”和“ next”（又称“ devel”）分支永远不会合并到master。它们是“暂时的”或“短暂的”，总是被删除/重新创建。
仅feature个分支合并到生命周期分支（public，next，master）。 这意味着您可以随时选择在开发生命周期的一个阶段与下一个阶段之间放一个feature。