问题标签 [git-flow]

在 Gerrit 中使用 git-flow 功能分支是否有推荐的工作流程？有什么最佳实践吗？

我们正在与多个开发人员和一个由 Git 管理的中央存储库启动一个项目。在使用 git-flow 时，我遇到了将功能分支推送到 Gerrit 的问题，作为在功能未完成时备份开发人员工作的一种方式：

我们不希望在开发过程中审查功能分支，因此我们允许所有开发人员直接推送到 refs/heads/feature/* ，绕过神奇的审查分支。我们希望在功能分支合并到开发分支时进行审查，但是当开发人员在合并后将她的工作推送到 Gerrit 时，只有合并提交需要审查。在功能分支中所做的更改不会出现在此补丁集中。我认为这是因为这些更改被直接推送到 refs/heads/feature/* 所以 Gerrit 认为他们不再需要审查。

开发人员是否应该在完成功能分支之前将功能分支推送到 Gerrit？为了能够做到这一点，她需要有权在 refs/heads/feature/* 和 refs/for/refs/heads/feature/* 上推送和创建引用，确保她只推送到审查分支。

任何帮助将不胜感激。

我已经阅读了@nvie 的Git 分支模型和gitflow，我认为这是一个很好的模型，可用于我目前正在开发的项目（Web 应用程序）。

我是该项目的首席开发人员，我在本地环境（类似 MAMP）上进行开发。每当我做了一些东西给客户看时，我都会提交我的工作并将其推送到中央 Git 主机。从那里我将它部署到连接到互联网的服务器上。然后我的客户可以看到更改。

第二个开发人员刚刚开始从事该项目。他一次开发单个功能，并在它们准备好时将它们推送到中央 Git 主机。我在部署之前回顾了他的工作。

目前所有提交都在master分支中完成并部署到单一托管环境。将来我想拥有一个生产环境（用于实际使用）、测试环境（在应用程序的新版本发布之前测试它们）和一个开发环境（我可以在其中展示已完成的功能或仍在进行中给客户）。我认为生产环境将从中部署master，而开发环境将从中部署develop。

我的问题如下：

1. 我经常同时处理多项任务。当某个功能的一部分准备就绪时，有时我想在继续开发该功能之前将其展示给我的客户。但是，据我了解，一个功能（分支）只会develop在它完成并计划发布时才被合并。如何向我的客户（在开发环境中）显示正在进行（或尚未计划发布）的功能？

2. 我应该从哪个分支部署到测试环境？我应该手动选择那个时候的发布分支，还是有一个专门的测试分支？

我最近开始开发一个新库，并使用 Git 进行版本控制。我决定关注广受欢迎的博客文章A successful Git branching model来管理分支。现在是我发布第一个版本的时候了，我想要一些关于管理特定文件集的建议，如下所述。

在开发分支和功能分支上，我想要所有的“支持文件”，例如用于编译的 makefile 和 doxygen 用于生成文档的 readme.md 文件。（请注意，这些只是几个示例。我还有更多“支持文件”。）

博客文章还说，提交到 master 分支是定义上的发布。我希望该版本包含所有“二进制文件”（例如，包括编译产生的目标文件和包含文档的 html 文件）。这些文件应该提交到主分支，以便客户可以从带有标签的存储库中克隆并获得所需的版本。

我不想在版本中包含“支持文件”（因为我不想给客户一堆他们不想要或不能使用的文件）。同样，我不希望在开发和功能分支中对“二进制文件”进行版本控制。因此，我想提交一组文件来开发，另一组文件来掌握。（当然，还有一组文件对两个分支都是“通用的”。）但是，我对保持主分支和开发分支不同步持怀疑态度，就像刚才描述的那样。

我提出的模型听起来不错吗？如果是这样，我应该如何处理提交开发和掌握的不同文件？有没有更好的方法来处理这种情况？

我浏览了上述博客页面上的每一条评论，搜索了互联网，也在 StackOverflow 上搜索了这里。从搜索结果来看，这个带有一些不同文件的帖子 GIT 存储库似乎是唯一一个接近我的问题的地方。这些都没有帮助我找出解决方案。

我正在尝试在我们的开发过程中应用 gitflow 方法，理论上我喜欢它。但是有一点是任何地方都没有涵盖的...

每个人都将他们的结果推向develop分支。在计划中，我们有 10 个问题应该完成并发布到测试版，然后发布到生产环境。10 个问题中的 2 个没有最终修复，但部分已经在开发分支中，因为开发人员认为他做得很好，但经过测试，错误又来了。现在决定我们不需要等待 2 个问题将得到修复，我们需要进行上传，这意味着创建release分支并在 beta 上进行测试。

在原始的 gitflow 文章中说：

从develop分支出一个新的release分支的关键时刻是develop（几乎）反映了新版本的期望状态。至少所有针对要构建的版本的功能都必须在此时合并到开发中

但是如果在develop分支历史中我们可以看到一对不需要的合并怎么办？我需要以某种方式切割它们吗？还是做其他事情？

谢谢。

我很难理解如何在 SourceTree 中正确合并修补程序（在 git-flow 意义上）。SourceTree 网站指出：

完成更改后，修补程序分支将合并回主分支（以更新已发布版本）和开发分支（以确保修复程序也进入下一个版本）

但是当我在 SourceTree 中完成一个修补程序时，我得到了这个：

实际上，Sourcetree 确实将修补程序合并到 master 和 develop 中，但这显然导致这两个分支出现分歧，这迫使我再次手动将 development 合并到 master 中。由此产生的结构很丑陋。

在修补程序之前，master 和 develop 都在同一个提交上。因此，我希望在修补程序之后，SourceTree 会通过快进将这两个分支与修补程序分支合并，基本上得到一个像这样的简单布局：

在这里，修补程序“修复更多...”就像一个简单的提交一样可见。是否有任何选项可以导致 SourceTree 通过如此简单的快进合并在修补程序中合并，基本上同时推进 master 和 development？有什么我可能会错过 aobut git 或 git-flow 的吗？

我在我的网站上使用 gitflow，但是我使用 Git 下载了一个 3rd 方库，我无法将它添加到我的主存储库中。如果我尝试，我会收到以下消息：

致命：路径“文件名”在子模块“SUBMODULE_NAME”中

如果我跑步，cat .git/config我会得到：

如果我做find . -name ".git*"

./libs/3RD_PARTY_NAME/.git

./libs/3RD_PARTY_NAME/.gitignore

./.git

./.gitignore

git status 说：

如果您需要更多信息，请告诉我。

谢谢

我正在尝试向我的团队介绍 Git 流程。我们是一个相当小的团队，而且非常敏捷。我们希望每天发布一次，这意味着我们只有有限的时间来测试当天的所有更改。业务团队希望能够控制正在发布的功能，尽管这并不理想。

Git 流程似乎不能很好地适应这一点。从开发中删除发布分支后，将所选功能合并到主控的最佳方式是什么。樱桃采摘是唯一的选择吗？有没有更好的办法？

我们已经有几个功能和发布分支，目前还没有被 git flow 跟踪（我们只是遇到了 git-flow）。

有什么方法可以将它们原样添加到 git flow 中？所以他们可以在以后被跟踪和合并？

谢谢

我最近加入了一个新的开发团队，我们正在将 Git 和 Git Flow 分支模型整合到我们的工作环境中。

到目前为止，我们已经在远程仓库中设置了开发和主分支。开发分支有一个自动钩子，当看到推送时，它会将代码部署到我们的暂存区。我还刚刚创建了一个包含生产就绪代码的标签。

我现在的问题是，从该州转向生产的最佳方式或行业标准是什么？

我看到的一些选项是：

1. 从生产位置的标签版本克隆 repo。然后在将来从新创建的标签中提取。
2. git archive <tag> | tar -x -C /path/to/live/site每次我们想要使用新标签进行生产时，手动执行类似于此的命令。

我需要将现有项目集成到 GitFlow 分支模型中。到目前为止，我看到的所有指南都以明确的回购为基础。是否可以在现有 Git 存储库上运行 GitFlow 并保留当前历史记录？