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

问题描述

我一直在阅读这个流行文档来尝试起草我自己的 git 工作流程.

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

我们有两个分支将始终保持活跃.

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

我们有多个主题分支，它们将从开发分支分支出来(我认为).一旦主题(例如错误)被修复，我们将该分支合并回开发分支.一些示例:

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

准备发布

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

创建发布

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

我学到的附注

master 分支总是很好而且干净，并且只包含发布的提交(我认为这就是为什么我们有一个单独的发布分支，对吗?).

请让我知道我在哪里搞砸或误解了什么等.谢谢！

解决方案

你的总结是准确的:你可以找到插图 在本备忘单中.

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

区别在于:

• 使用 git flow:
  • 多个 feature 分支在 devel 中合并(在那里他们发现它们是否可以一起工作)
  • 然后 release 在合并回 devel(和 大师).
• 使用 gitworkflow:
  • feature 分支合并到一个public"；阿尔法"分支，在每次发布后重置(意思是，在新发布的基础上删除/重新创建)
  • 然后将那些相同 feature 分支的子集合并到next"；(beta") 用于集成/验收测试的分支.那个next"(beta") 分支类似地在每个新版本之后在 master 之上重新创建.
  • 然后将 feature 分支的子集合并到 master，以准备下一个版本.

public"和next"(aka 'devel') 分支永远不会合并到 master.它们是瞬态的"或短暂的"，总是被删除/重新创建.

只有 feature 分支被合并到生命周期分支(public、next、master).这意味着您可以随时选择在开发生命周期的一个阶段和下一个阶段之间删除功能.

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屋！