问题标签 [feature-branch]

我有一个使用功能分支和 Git 的典型用例，如下所示：

我想将我的功能分支重新定位到 master 上，而不应用来自分支“1.24”的提交，我已经设法从指定所有参数的命令行执行此操作，但我仍然无法从 eclipse 中找到执行此操作的图形方式。

你对这些案件怎么办？合并对我来说也是如此，我相信这是 GitFlow 工作流中非常常见的场景。

我们有一个典型的工作流程，在 Git 功能分支上进行开发。master 上的更改被拉入特性分支，完成后，特性分支被合并到 master 中（大部分工作没有冲突）。

功能分支在 Jenkins 上不断构建（每个分支一个项目），尤其是为了运行在开发机器上难以完成的测试。这些构建的结果（失败或成功）的通知必须发送给相关的开发人员。从实际的角度来看，所涉及的开发人员是那些在功能分支上工作的人。没有必要让所有这些开发人员都收到通知，将通知发送给对分支进行最后一次更改的人就足够了（意思是：更改分支 HEAD 的值）。

问题是：如何以编程方式确定这些开发人员？我知道这可能不可能 100%，目标是找到一个可行但不完美的解决方案。

绝对不能发生的事情是从未在分支上工作过的提交作者收到通知。当 master 合并到分支中并且在初始分支创建之后，有（很多）提交作者与分支无关。

我会将我想到的方法作为答案，但如果有更好的解决方案，我很感兴趣。

我正在寻找一种将更改合并到主分支后将更改引入功能分支的方法。目标是保持功能分支只包含与其相关的提交。

经常发生的情况是，一个特性在被推送到 master 之后还需要一些额外的打磨。在此期间对 master 所做的更改与功能不冲突，这意味着在功能分支上实现附加工作时，可以将 rebase 变为实际的 master。

下图显示了这种情况：

到目前为止我使用的方法：Rebase to master and merge feature back to master

反对 -> 功能分支现在被 master 的部分污染了。

问题： 您在实践中采取了哪些方法来解决这个问题？

示例代码

为了帮助描述下面的方法，是从示例中创建 repo 结构的代码。

以下是场景，我想了解并可能为团队成员编写步骤 - “如何” 场景：在任何现实世界场景中，我们都有大师。故事分支被创建和处理并推送给 Master。这是为了持续集成。然后我们发布了据我所知，它们现在的设置方式是使用标签进行发布。

我的问题：

由于应用程序的方式，我们现在需要让我们自己的项目分支说“A1”并且它是从 Master 创建的。一个自动化的工作会定期将 master 拉入“A1”（冲突将被警告，我们会在“A1”中处理它

我将要求我的团队成员从 A1 创建专题故事分支

假设 2 个开发人员现在从 A1 创建了 C2 和 B4 分支，完成后，它们将保持为 C2 和 B4 分支，但还需要合并到 A1，所以下一个特性故事分支 E7 可以接取在 C2/B4 中完成的事情在A1项目阶段。

请帮助实现这一目标的步骤。

在最终将其合并到 master 之前，我如何将 feature-story 合并到 A1 中（这样做是否正确）？

我也没有完全了解是否（以及如何）使用 A1 重新设置功能，这是否需要？

感谢您的所有帮助。谢谢。

我正在与一个团队一起使用 Git Flow。我们都从开发功能分支出来，并在代码审查后重新合并。它对我们来说效果很好，但是我们现在有一个功能需要开发人员一个多月才能完成。我们将在这段时间内发布一些版本。

有几个问题可以推动这一点：

• 我们应该如何处理？
• 我们应该这样处理吗？
• 还是我们应该将功能拆分成更小的合并请求？
• 如果我们将其拆分，并且它是一个公共项目，我们如何确保此功能的某些部分不会影响正在进行的发布？
• 合并开发到这个长期的特性分支真的那么糟糕吗？我的同行担心它是反模式的。
• 如果我们不将开发一致地合并回这个长期功能，当功能最终完成时会不会产生不好的后果？

在我的办公室，我们正在使用 git 并进行一些代码审查。来审查我的同事的时间要求我将源分支（主）合并到我的功能分支中，以便能够看到差异并进行审查。我并不同意，因为在我看来，功能分支应该只包含功能的提交，因此不导入主分支更改。

所以我想知道在创建一个长期存在的共享特性分支时，我是否应该在任何时候将源分支合并到特性分支中？

当启用 git rerere 时，我已经看到了一些解释，您将源分支合并到功能之一以记录潜在冲突的解决方案，然后恢复提交的合并。

我想知道什么是最佳做法。

我负责我公司的面向客户的服务，到 3 月底，我们将以“大爆炸”的方式重新命名我们的公司，因此我们所有的产品都在那天发布，具有新功能和新 CI .

我估计我必须做的工作是 1-2 天，但为了有足够的时间与我们的设计师交流，我可能会在 3 月初开始。部署是直接从主分支的负责人安排的，所以我想知道如何进行品牌重塑。如果我在 master 上执行此操作，我必须从发布分支部署服务，在该分支中我挑选非品牌重塑提交半个月。这意味着我必须为其他开发人员，尤其是管理人员禁用对部署管道的登录，因为意外部署新 CI 太容易了。

从这个角度来看，它可能看起来像一个特性分支是要走的路，但那不是很丑吗？正确的方法是什么？

我克隆了一个hgrepo 并创建了一个功能分支（通过hg branch myfeature）。hg add .我已经通过然后随后对它进行了上演并提交了更改hg commit -m "My new feature branch."。

我现在想将这些更改（在分支中；而不是as default）推送到远程服务器（我从中克隆项目），以便其他开发人员可以对myfeature分支中的更改进行代码审查。

我发现了一个推荐使用的博客：

但这对我不起作用 - 我有什么想法会出错吗？

我试图理解为什么有些团队已经在使用功能分支并尝试实现持续交付时使用功能切换。假设一个团队想要实现持续交付，并且可以在功能切换或功能分支的帮助下做到这一点。

通过功能切换，可以实现所谓的“发布切换”，使团队能够更快地发布。如果某个功能尚未准备好并且您仅使用主分支，则可以切换它并发布代码。

特征分支的情况几乎相同。在这里，您可以拥有 3 个正在开发的功能，其中一个已经完成。然后，公司希望团队部署到生产环境。他们只选择该功能并将其合并并发布。

我看到一些团队在开发时同时使用这两种方法。有这方面经验的人能告诉我一些有关它的事情吗？

希望你能理解。

我对以前使用过 svn 的 git 感到有些困惑。

我已经从主分支拉出，创建了我的功能分支，对其进行了处理，在本地添加并提交了我的更改，推送到远程，然后将我的分支提交给 jenkins，所有测试都通过了。

与此同时，主分支已经转移，所以我检查了开发，提取了最新的更改，然后根据最新的开发副本重新建立我的分支。

所以这意味着我的单元测试和集成测试针对的是我的代码的最新副本，而不是最新的开发副本。

我以为我现在可以再次将 chanegs 推送到我的远程分支，以对其进行最新的开发更改，然后重新运行我的测试，但是 git status 说没有什么可以提交并且我的工作目录是干净的。

为什么我的分支没有识别出我可能想要推送以重新运行我的测试的开发更改？