【发布时间】：2013-08-13 20:28:37
【问题描述】：
【问题讨论】：
【发布时间】：2013-08-13 20:28:37
【问题描述】：
正如 GitMinutes 第 17 集所述，Nicholas Zakas 在他关于“GitHub workflows inside of a company”的文章中：
Git-flow 是一个管理 Git 更改的流程，由 Vincent Driessen 创建，并附有一些用于管理该流程的 Git extensions。
git-flow 背后的总体思路是拥有几个始终存在的独立分支，每个分支用于不同的目的：master、develop、feature、release和hotfix。
在最终发布之前，功能或错误开发过程会从一个分支流向另一个分支。一些受访者表示他们一般使用
git-flow。
有些人从git-flow开始，然后离开了它。离开的主要原因是
git-flow流程在连续（或接近连续）部署模型中难以处理。
总体感觉是git-flow适用于产品采用更传统的发布模式，即每隔几周发布一次，但当您每天发布一次或更多时，此过程会大大中断。
简而言之：
从尽可能简单的模型开始（如 GitHub 流程往往如此），如果需要，再转向更复杂的模型。
您可以在以下位置看到基于GitHub-Flow 的简单工作流程的有趣插图：
“A simple git branching model”，主要元素为：
master必须始终可部署。- 通过功能分支进行的所有更改（拉取请求 + 合并）
- rebase 以避免/解决冲突；合并到
master
如需实际更完整、更强大的工作流程，请see gitworkflow (one word)。
【讨论】：
-
rebase 以避免冲突？？？
-
@stopsopa 这意味着在本地解决冲突（在变基期间），以便合并成为一个微不足道的快进。
-
在示例中的简单 git 分支模型链接中，我不理解 git rebase origin/my-new-feature 行。关于 prev 行，是不是把主分支移到 my-new-feature 分支的顶端，这绝对是一个 nodo，我的意思是 rebase 一个公共分支？
-
@g.pickardou 它不会移动主分支，因为首先有一个
git checkout -b my-new-feature。但这也不是必需的。重新定位像master/main这样的公共分支确实是不行的。 -
谢谢，看来我必须在下一个将来就这个话题做功课
没有每个人都应该遵循的灵丹妙药工作流程，因为所有模型都不是最佳的。话虽如此，您可以根据以下几点为您的软件选择合适的模型；
生产中的多个版本 - 使用 Git-flow
如果您的代码在生产中有多个版本（即典型 软件产品，如操作系统、Office 软件包、自定义 应用程序等）您可以使用 git-flow。主要原因是你需要 在生产中持续支持以前的版本，同时 开发下一个版本。
生产简单软件的单一版本 - 使用Github-flow
如果您的代码在生产中始终只有一个版本 （即网站、网络服务等）您可以使用 github-flow。主要的 原因是您不需要为开发人员复杂的事情。 一旦开发人员完成一项功能或完成错误修复，它会立即 升级到生产版本。
生产中的单一版本但非常复杂的软件 - 使用 Gitlab-flow
Facebook 和 Gmail 等大型软件，可能需要引入 部署分支在您的分支和主分支之间，CI/CD > 工具可以在其中运行，然后再投入生产。想法是 为生产版本引入更多保护，因为它被使用 数百万人。
【讨论】：
-
只需将“Gitdmz-flow”/“Git DMZ Flow”添加到列表中：gist.github.com/djspiewak/9f2f91085607a4859a66
-
引用的公司使用基于中继的系统。 paulhammant.com/2014/01/08/…
-
Git DMZ 流程更类似于 Gitflow，DMZ 分支类似于开发分支。所以我觉得没什么特别的。
-
据我了解，Git-Flow 不适用于多生产版本。修补策略假设您只有一个生产版本，并且您在相应的发布分支上进行修补（然后将其合并回开发分支）。它似乎不满足您如何修复多个生产分支中存在的一个错误。
-
@GayanPathirage 实际上不是。 1. master 上的“经典”GitFlow 标签。 Hotfix 分支仅供您针对最新的生产版本（来自 master）进行修复。 2. “发布分支”是Gitflow中的其他意思，实际上是发布前的预览分支（从develop分支分支出来，目的是在真正发布时合并到master）。 3. 您指的是 GitFlow 中称为“支持分支”的东西（这是我不喜欢 GitFlow 的原因之一：非常规术语）。然而它仍然是实验流程（所以你在大多数 Gitflow Intros 中看不到它）
我已经使用 git-flow 模型一年多了，没问题。
但这实际上取决于您的应用程序将如何开发和部署。
当您的应用程序开发/部署流程缓慢时，它会很好地工作。
但是例如，像 GitHub 一样，我们有一个具有快速开发/部署流程的应用程序，我们每天部署，有时一天部署几次，在这种情况下，我认为 git-flow 往往会减慢一切，并且我使用 GitHub 流。
另外一个要考虑的是，git-flow 不是标准的 git，所以你可能会曲线，更多的机会把事情搞砸。同样如上所述，有人开发了一套脚本，让 git-flow 的使用更容易，所以你不必记住所有命令，它会帮助你使用命令，但记住实际流程是你的工作，当开发人员不知道它是修补程序还是功能时，我不止一次遇到过，或者更糟糕的是，他们不记得流程并把事情搞砸了。
至少有一个 GUI 支持 Mac 和 Windows 的 git-flow SourceTree。
这些天来，我更倾向于 GitHub Flow，因为它简单且易于管理。另外，由于“经常部署早期部署”......
希望对你有帮助
【讨论】：
-
+1。我同意你的看法。
-
GitHub 流在 Git-Flow 中。想想如果您需要持续集成和持续部署，您可以简单地使用开发分支尽可能多地运行。每个功能都是从开发分支分支出来的。除非您有复杂的部署模型，否则您可能不需要主分支或发布分支。 （例如，您的 1.1 版本在某个客户端上运行，您的 1.2 在另一个客户端上运行，目前您为新客户端开发 1.3）所有 3 个客户端都将要求对各自版本进行错误修复和更改。
-
您好 Diego，感谢您的回答。多版本维护呢？你用 Git Flow 很容易做到吗？我听说这很困难，因为您需要支持分支！您认为该模型非常适合这样做吗？
-
嗨 Luis，我认为您可以使模型工作，但我再次觉得您可以使用标准 git 工作流程实现相同的目标。
-
@LuisGouveia 实际上，由于您的问题和我上面的回复，我遇到了一个项目，git-flow 可以完美运行，并且我拥有该项目的所有权。这个想法是使用
git flow release...与 github 操作组合来部署应用程序。在我最初的回复中，我提到我们一天发布多次，这导致使用 git-flow 时出现问题。我认为 git-flow 会在这个项目中运行良好的原因是因为我们有一个预定义的发布周期，这是使用 git-flow 的主要卖点之一。