问题标签 [git-flow]

我正在尝试使用 Gerrit 实现“git-flow”类型的工作流，但我似乎无法弄清楚最后一块拼图。

我的问题有两个先决条件：

• Gerrit 只会合并到一个分支
• 我不允许将合并提交推送到 Gerrit。更改获得批准后，合并必须由 Gerrit 完成

我要解决的问题如下。考虑这种 git 情况：

有一个带有一个提交的 master 分支和一个从 master 派生的带有几个附加提交的开发分支。一段时间后，develop 分支合并回 master 以创建下一个生产版本。开发人员使用来自开发的主题分支和严格的变基。在推送之前，他们的提交总是基于最新的上游开发。这应该会导致线性历史记录，并且只会快进提交。

现在假设有人从 master 创建了一个 hotfix 分支并合并回 master：

这个提交现在只合并到主分支，但开发人员需要在他们的开发分支中提交这个提交，以将错误修复合并到他们的更改中。通常你会合并主分支来开发开发分支，但考虑到我的先决条件，这是不可能的，因为它会创建一个本地合并提交。

我的问题是：如何将主分支的新提交合并到本地开发分支中，以便开发人员的任何新更改都包含错误修复？理想情况下，我会修改我的脚本以首先将错误修复更改应用到本地开发分支（合并但没有合并提交），然后重新设置开发人员的提交并推送。这样，错误修复将自动添加到他们的新更改中，并将被视为新提交的一部分，而不是单独的提交。

我一直在考虑可能的解决方案：

• Cherry 选择提交到开发分支。我相信下次开发与 master 合并时，这将始终导致重复提交。有没有办法解决？
• 如此处所述的变基： http ://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/ 。自从发布了开发分支后，这可能会导致问题，或者不会？

我希望我的问题很清楚。如果需要进一步澄清，请告诉我。我知道我的工作流程非常严格，但与 Gerrit 结合使用将是理想的选择。如果它不能完成，那么我可能会允许合并提交......

我正在使用 git-flow 和许多主题分支，也就是功能分支。当我决定采用完全不同的路线时，我正在开发一个功能分支。

我现在想删除那个分支，因为那里的工作不会合并到 development 或 master 中，它只会“混乱”分支列表。

但是出于历史和管理目的，我想将历史记录保留在该分支中（以及我们都再次改变主意并且必须挖出存档的工作的奇怪机会）。

最好的路线是什么？我可以简单地git branch -D让它在稍后的时刻死亡吗？如果是这样，这样做的命令是什么？

我喜欢让我的功能分支与开发保持同步。经常做“git merge --no-ff develop”有什么问题吗？最后，运行“git flow feature finish feature1”。这些功能分支是共享的（这意味着其他人可能正在处理它，或者我正在家里的计算机上开发它），主要是因为我喜欢知道它们在其他地方备份。如果它们不被共享，是否会优先选择持续变基？

还是最好不要让您的功能分支保持最新状态，而只在最后合并所有内容？

我正在遵循此处描述的工作流程，因为我发现许多指向此页面的参考资料都是一个很好的工作流程。正如文章中提到的，“功能”分支在开发人员之间共享，但不要转到中央存储库。

假设开发人员“A”使用git checkout -b newfeature develop. 现在假设开发人员“B”也需要处理此功能。这是我的问题。

我做了什么：

1. 开发人员“B”将开发人员 A 的机器添加为远程
2. 开发人员“B”运行git branch remoteA/newfeature
3. 开发人员“B”在这个分支上工作，提交他的工作并将更改推送回 remoteA。

步骤 3 不工作，现在。我收到一条消息：

远程：错误：默认情况下，在非裸存储库中更新当前分支是被拒绝的，因为它会使索引和工作树与您推送的内容不一致，并且需要'git reset --hard'来匹配工作树到头。

远程：错误：您可以在远程存储库中将“receive.denyCurrentBranch”配置变量设置为“忽略”或“警告”，以允许推送到其当前分支；但是，除非您安排更新其工作树以匹配您以其他方式推送的内容，否则不建议这样做。

远程：错误：要压制此消息并仍保持默认行为，请将 receive.denyCurrentBranch 配置变量设置为 'refuse'。

我已经设置了sharedRepository = true，但它没有帮助。

我有两个问题：

1. 在开发人员之间共享功能分支的正确方法是什么？
2. 如何将开发人员 B 存储库中的更改推回开发人员 A 的原始存储库？

我目前正在研究 git-flow，并试图弄清楚如何将它用于我参与的项目。

我看过各种 git-flow 教程，我对 git 相当熟悉。因此，我不需要任何关于 git 的提示，而是直接使用 git-flow 的工作流程。

情况如下：

当我发布一个版本（我们称之为 1.0）时，这个 get 是开发的分支，这很好。假设现在我开始研究 2.0，添加新功能。当然，一旦完成，我想将它们合并回开发中。现在在 1.0 上修复就可以了，所以假设我生产了几个版本 1.0.1、1.0.2 等。所有这些也会更新开发分支，这也很好。到目前为止，现在很麻烦，我可以独立开发 2.0 的功能和 1.0.x 的修补程序。

但是，假设有人要求 1.1 版本的新功能。现在我有一个问题。如果我创建一个特性分支，这将基于开发分支，它可能已经包含 2.0 的东西，我可能不希望在这个 1.1 版本中。

有没有一种简单的方法来独立处理这些 2.0 和 1.1 的更改？

我已经看到了几种可能性：

• 在开发的最后一个发布位置创建一个新分支。将开发重新定位到此位置并重命名另一个开发分支。但是，此分支将不包含来自 1.0.1 等的任何修补程序。

• 在 2.0 完成之前不要合并 2.0 的功能。但是，我将不得不保留许多未合并的更改，直到最后一刻。这也无济于事，如果 2.0 get 发布并且随后请求更改为 1.0.x。

这对 git flow 有可能吗？即，一旦新版本的工作已经开始甚至完成，就基于早期版本发布？

我是 git 和 git flow 的新手。我已经阅读了所有关于它的各种页面、博客和 stackoverflow 问题，并且一直在我的日常开发中使用它。

但是一个问题一直困扰着我，我就是无法解决它。我知道特性分支应该很小，你开始一个特性，编码它​​的一部分，然后完成这个特性。这是每天都会发生的事情，我明白了。我们只是确保我们的开发分支始终是可构建的。

但是当我在一个功能的中间，它还没有准备好完成，但是工作优先级发生变化时会发生什么？我希望能够切换到另一个功能。

例如，我启动了一个新功能。

我编写代码、提交文件等......并且在这方面取得了良好的进展。但是现在我需要更改我正在处理的内容，主要是因为我需要一个不可用的资源，而服务器编码器一两天内都无法准备好它。我无法完成该功能，因为它会破坏开发分支。

我想做这样的事情：

事实上，“git flow feature list”命令的存在意味着我可以同时拥有多个功能。但我看不到如何创建或在功能之间切换。事实上，我开始认为这根本不是 git flow 问题，而是 git 问题。

我很感激任何帮助。谢谢！

我们刚刚开始将 git 用于我们的生产代码，我们在工作流程中遇到了一个小问题。我们需要弄清楚如何处理在开发功能时出现的一般代码改进/技术债务修复。

我们采用的工作流程是使用“开发”作为主要集成分支，并在“开发”的功能分支上开发所有功能。当一个功能完成后，开发人员会创建一个拉取请求，每个人都会对其进行审核以提供评论，然后再将其合并回开发中。这似乎工作得很好。

我们遇到的问题是，在功能的常规开发过程中，开发人员可能最终想要修改/重构一些通用代码以改进系统或清理一些技术债务。此更改很有价值，但与正在开发的功能没有直接关系。

根据我们的工作流程，它应该在另一个分支上完成，该分支在进入开发之前经过它自己的拉取请求和代码审查。如果我们让他们这样做，他们如何在等待完整的代码审查和合并到开发中的代码的同时将更改恢复到他们的功能分支上。

我们的想法是：

1) 将“refactorX”分支中的更改挑选到我们的特性分支中。继续开发并让 git（希望）弄清楚我们何时合并回开发它已经具有来自重构分支的更改。

2) 将“refactorX”分支合并到我们的特性分支中并继续开发。（注意：'refactorX' 的分支开发可能在开发历史的后期，所以我们认为这可能有问题）

3）我们还不知道的其他一些更聪明的选择。:)

我们正在寻找的是一些关于如何处理这部分工作流程的最佳实践指南。在谈论它更多之后，我们知道它会经常出现，我们希望在我们的工作流程中找到一种平稳有效的方式来处理它。

有什么建议吗？

我仍在尝试从 git 转向 git-flow。我知道我可以在 git-flow 中使用任何类型的 git 功能，但我最感兴趣的是它自动处理的内容。

假设有两个开发人员 Alice 和 Bob，分别在功能 A 和 B 上工作。当 Alice 完成后，她可以根据提交 Cgit flow feature finish A在她的本地分支上创建一个合并提交develop。现在如果 Bob 同时完成了他的功能，并且他获取了相同的东西，他的合并提交也将基于 C . 现在如果 Alice 推送然后 bob 再次获取，他将不得不合并或变基，我们最终会在分支上得到非线性历史develop，以防他合并。

到目前为止这是正确的，还是 git-flow 以某种方式自动处理这种情况？如果有一些自动机制，必须设置什么才能使其工作？

最简单的解决方案可能是始终develop在完成功能之前获取。但是，我不确定这实际上是否可行，具体取决于共享存储库的方式（当时可能不可用）。

编辑（问题的澄清）：

正如答案所暗示的那样，我的例子并不清楚。所以首先我认为是问题的图片：

C 是开发分支上的初始提交。

Alice 在特性分支上创建了一些特性工作：

同时，Bob 也为另一个功能工作

现在 Alice 完成了这个功能并且合并提交被添加到开发中（我想要那个）。

现在 Bob 完成了这个功能，并再次添加了一个合并提交来开发（我也想要那个，只是在另一个地方：

然而现在 Alice 或 Bob 必须合并开发，创建一个额外的提交：

我想要的是这样的：

如您所见，历史仍然是非线性的，但是开发分支的主线仅包含来自功能的合并提交（并且在其他情况下没有额外的合并提交）。

我喜欢这一点的是，您可以轻松地跟踪历史中的更改，并查看它们是否属于以前的功能分支，或者它们是否在开发中合并。所有这些信息都可以直接从 DAG 中获得。

此外，如果您在开发中为合并提交使用好的消息，在第二种情况下，您可以通过始终关注开发中的第一个父级轻松导出更改日志。但是，在第二种情况下，您有时只需要关注第一个父母，有时需要关注多个父母。而且我看不到什么时候可以编写代码的简单方法。

我们正在过渡到 git，我们需要更好地处理分支和并行开发的源代码控制。我们整个团队都做了一些研究，我们决定转向 git。我们也喜欢gitflow的模型。我注意到 git 还有一个 gitflow 扩展。

这个扩展比标准 git 有什么好处？它似乎主要是用于捆绑命令的宏。我们是否应该为 gitflow 扩展而烦恼（我们确实喜欢这个模型）？有用吗？它与标准 git 命令相比如何？

我已经使用git-flow有一段时间了，但我仍然不了解 Tag Prefix 功能。我假设它只是一个为每个release/标签添加前缀的字符串。有没有人有任何使用示例或这样做的好处？我还没有在任何 Git Flow 博客文章中看到任何解释。