尝试理解/确定基本的 Git 工作流程

Ric*_*ich 3 git version-control merge github

我一遍又一遍地阅读这份流行文档,尝试起草我自己的 git 工作流程。

我想我已经明白了,但我还是有点失落。这是我目前的理解...



我们有两个分支机构将始终保持活跃。

  • Master:这是我将推送实际部署到我的生产服务器并由我的用户使用的代码的地方。
  • 开发:这将从主分支中分支出来。它将包括我的所有新功能、错误修复等,这些功能将被推送到下一个版本中。


我们有多个主题分支,这些分支将从开发分支中分支出来(我认为)。一旦主题(例如错误)得到修复,我们就会将该分支合并回开发分支。一些例子:

  • 主题分支 1:feature-ajaxify-shopping-cart
  • 主题分支 2:bugfix-navbar-font-overlapping


准备发布

  • 我们一次有 1 个发布分支,它们将从功能分支中分支出来。
  • 现在我们拉/合并所有我们想要推送到下一个版本的功能、错误修复等。
  • 我们可以保留一些我们一直在开发的功能,这些功能不会出现在下一个版本中(我认为)。


创建版本

  • 一旦对发布感到满意,我们就可以将该发布分支合并到主分支中,并将提交命名为“v1.2.0”。
  • 我们还想用“v1.2.0”标记该提交,以便我们可以轻松地返回过去并查看版本。


我学到的旁注

主分支总是干净整洁,并且只包含发布的提交(我认为这就是为什么我们有一个单独的发布分支,对吧?)。

请让我知道我哪里搞砸了或误解了某些东西等。谢谢!



Von*_*onC 10

您的总结是准确的:您可以在这份备忘单中找到说明。

但请注意,为了与其他功能一起测试您的功能,您必须将它们合并起来进行开发 ( git flow feature finish MYFEATURE)。
还有另一个工作流程(Git 工作流程)可以更好地提升功能(开发,然后发布)

区别在于:

  • 使用git流
    • 多个feature分支被合并devel(他们发现它们是否可以一起工作)
    • thenrelease是从devel(此时删除特征变得复杂)创建的,然后合并回devel(and master)。
  • 使用 gitworkflow
    • feature分支被合并到“ public”“alpha”分支,该分支在每次发布后都会重置(意味着在新版本之上删除/重新创建)
    • 然后将这些相同分支的子集合feature并到“ next”(“beta”)分支以进行集成/验收测试。next在每个新版本发布后,同样会在其之上重新创建“ ”(“beta”)分支master
    • 然后将分支的子集合feature并到master,以准备下一个版本。

" public" 和 " next" (又名 ' devel')分支永远不会合并到master。它们是“暂时的”或“短暂的”,总是被删除/重新创建。

feature分支会合并到生命周期分支 ( public, next, master)。这意味着您可以随时选择在feature开发生命周期的一个阶段和下一阶段之间进行切换。