试图了解/确定基本的Git工作流程 [英] Trying To Understand/Determine A Basic Git Workflow

问题描述

我一直在阅读热门文档，尝试起草我自己的git工作流程.

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

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

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

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

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

准备发布

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

创建发行版

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

我学过的笔记

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

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

解决方案

您的摘要准确无误:您可以找到插图的 Git工作流程)，它可以更好地促进功能(开发然后发布) >

区别是:

• 具有git flow，多个feature分支在devel中合并(它们发现它们是否可以一起工作)，然后从devel创建release(这时删除功能变得复杂)然后再合并回devel(和master).
• 使用gitworkflow :
  • feature分支合并到"public""alpha"分支，该分支在每次发行后重置(意味着在新发行版的顶部删除/重新创建)
  • 然后将那些相同的feature分支的子集合并到"next"("beta")分支以进行集成/验收测试.每次发布新版本后，都会在master顶部类似地重新创建"next"("beta")分支.
  • 然后将feature个分支的子子集合并到master，以准备下一个版本.

"public"和"next"(又名"devel")分支永远不会合并到master.它们是短暂的"或短暂的"，总是被删除/重新创建.
只有feature分支合并到生命周期分支(public，next，master). 这意味着您可以随时选择在开发生命周期的一个阶段与下一个阶段之间删除feature.

I've been reading this popular document over and over to try and draft my own git workflow.

I think I have got it down, but I am still a little lost. Here is my current understanding...

We have two branches that will always remain active.

• Master: This is where I will push code that will actually be deployed to my production server and be used by my users.
• Development: This will be branched from the master branch. It will include all my new features, bug fixes etc that will be pushed into the next release.

We have multiple topic branches that will be branched from the development branch (I think). Once the topic, example the bug as been fixed, we merge that branch back into the development branch. Some examples:

• Topic Branch 1: feature-ajaxify-shoping-cart
• Topic Branch 2: bugfix-navbar-font-overlapping

Prepare The Release

• We have 1 release branch at a time that will be branched from the feature branch.
• Now we pull/merge all the features, bug fixes etc we want to push into the next release.
• We can leave some features we have been working on that wont be in the next release (I think).

Creating The Release

• Once satisfied with the releases, we can then merge that release branch into the master branch, and name the commit something like 'v1.2.0'.
• We also want to tag that commit with 'v1.2.0' so we can easily go back in time and see releases.

Side notes I have learned

The master branch is always nice and clean, and only contains commits that are releases (I think thats why we have a separate release branch, right?).

Please let me know where I have messed up or misinterpreted something etc. Thanks!

解决方案

Your summary is accurate: you can find illustrated in this cheatsheet.

Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).
There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)

The difference is:

• with git flow, multiple feature branches are merged in devel (where they discover if they can work together or not), then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).
• with gitworkflow:
  • feature branches are merged to a "public" "alpha" branch, which is reset after each release (meaning, deleted/recreated on top of the new release)
  • then a subset of those same feature branches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top of master after each new release.
  • then a sub-subset of feature branches are merged to master, to prepare the next release.

The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.
Only feature branches are merged to the lifecycle branches (public, next, master). That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.

这篇关于试图了解/确定基本的Git工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！