问题标签 [branching-strategy]

我们有发布分支，它们是 main 的分支。

我们也有从 main 分支出来的实验分支。

我们现在在一个实验分支中有一个特性，我们想将它添加到另一个实验分支。

问题是我们还不想将这些更改合并到 main 中，因为那样它会比计划更早地发布。

实现这一目标的最佳方法是什么？无根据的合并？实验分支不应该与主分支合并吗？

在 tfs 迁移（完全不同的分支概念）之后，我必须将修复合并到多个发布分支，但分支并不相同，它们大多相似，但产品不同（例如不同的品牌、conn 字符串等），所以我可以不要在这里使用 nvie gitflow 一种产品分支策略。

https://github.com/MrKekson/stackoverflow_question/network

在这里你可以找到一个大大简化的分支结构，基本上我想将 hotfix1 分支从 b1 合并到 tesztb3，但没有之前在 b1 上的提交（c3，c4）。

Cherrypicking 或 rebase 可能会有所帮助，但我没有设法完成它，而且我在高级 git 使用方面还没有很多经验。所以请告诉我如何去做，或者我应该改变什么来完成它。

我在 HP UFT 12.52 中有一个“主”脚本，它为应用程序的 gui 端运行测试并且工作正常。我们希望使用相同的数据表来驱动 Web 服务上的 GUI 测试。

主人使用 excel 表来驱动每个请求所需的值。我可以创建一个等效的“即时”来指向按钮后面的 API 调用。我有一列（APICall），它是要发送的肥皂请求的名称。

但是，当我开始测试时，我可以将工作表加载到包含操作的 API 测试中，但要让它获取 APICall 值并分支到适当的操作（由 API 请求命名）被证明是不可能的。该代码存在于 GUI 操作中的 VBScript 中。我不明白为什么在 API 方面这么难。

我也是一名初级 C# 程序员。

我想配置 BitBucket Cloud，以便拉取请求不会创建合并提交，而只会进行快进合并。

但是，我似乎找不到配置它的方法。对于 Bitbucket Server，似乎有一种简单的方法可以做到这一点：http: //blogs.atlassian.com/2016/08/new-features-bitbucket-4-9/

关于如何使用 Bitbucket Cloud 实现相同目标的任何想法？

我正在使用 TFS 2015 并在分支模型上苦苦挣扎。以下是我想要实现的目标：

目前我们有一个“Dev”分支，我们从其中为每个新的 sprint 故事采用一个新的“Feature”分支。我们完成编码，然后合并回“Dev”分支。这一点工作正常。

但现在我从“Dev”分支创建了一个“QA”分支，并希望应用以下编码/分支流程：

"Dev" 分支到 --> "Feature" 分支 --> 然后合并到 "QA" 分支。

现在，当我尝试从“Feature”分支合并到“QA”分支时，我遇到了没有定义关系的毫无根据的合并问题。

当然，“Feature”分支和“QA”分支都是从“Dev”分支分支出来的，所以我应该能够进行正常的合并。

所以我的问题是，我在这里错过了什么或做错了什么？

提前致谢。

我正在与 Visual Studio 和 TFS 合作，目前正在探索分支和合并的想法。概述我如何组织一个解决方案：

我一直在玩这个并创建了一个测试分支，并一直在测试“MyProject 1”和“MyProject1TestBranch”之间的合并更改。

将单个项目合并到这样的解决方案中是个好主意吗？如果多个项目共享另一个项目的代码怎么办？或者我应该对整个解决方案进行分支以保持简单吗？

如果最好对整个解决方案进行分支，那么这样做的优点/缺点是什么？我是否应该考虑使用完全不同的策略？

感谢任何反馈。我想在这个阶段我只是在寻找一些关于我是否朝着正确的方向前进的验证

我们对 Git 相对较新，将它与具有多个分支的分支设置一起使用，即不仅仅是有一个分支然后应用功能分支。

我们的分支模型由以下部分组成（按此顺序）：

• 硕士/生产
• 质量保证
• 系统测试
• 发展

到今天为止，我们首先将更改应用到开发和使用樱桃采摘到上面的下一个分支，即系统测试。然后我们再次对 QA 进行 Cherry Pick 并进行彻底的测试。更改不一定会交给 Master，因为某些更改可能会被搁置或推迟。

使用 Cherry Picking 对我们来说很麻烦，特别是如果更改是旧的并且包含许多提交。也存在破坏代码的风险，因为自动合并可能会失败。自动合并也很困难，因为源代码也包含二进制数据。

我们希望简化应用更改的步骤。在以前的项目中，使用功能分支是使这更容易的方法。我们在如何应用这种方法上苦苦挣扎，因为要考虑多个分支，并且某些更改可能不一定到达 Master。

我将尝试解释我们希望如何在我们的设置中使用 Git：

创建更改：首先从 Master 创建一个功能分支。任何更改都会推送到该功能分支。此功能分支只能从 Master 合并。

将更改应用于分支：功能分支合并到任何主要分支中，但首先是开发，然后是系统测试等。功能分支可以用于 QA，但不一定用于 Master。某些功能分支可能与以后的更改有关，并且可以搁置更长的时间。

哪种策略最适合使用 Git 的这种分支模型？我们如何才能以最好的方式使用 Git 以实现它应该如何使用。

我们正在使用与 Jira 和 Bamboo 集成的 BitBucket 作为我们开发过程的一部分。我真的很喜欢从 Jira 导航到 Bitbucket 的想法，能够在 Jira 上查看拉取请求状态，并在 Jira 上构建信息。还能够直接从 jira 针对用户故事创建功能/错误修复分支。但即使在将功能分支合并到主分支之后，我也不喜欢保留分支。有没有一种方法可以在合并更改后删除功能分支，但在 Jira 上对此有一些详细信息。在我们的过程中，我们不会删除功能分支，我担心远程分支会在一段时间后膨胀。我还有什么其他选择？

首先，我想

1. 让我的master分支始终保持绿色。
2. 能够为下一个版本挑选更改。

分支策略：

1. 我有一个master分支和一个integration与它一起运行的分支。
2. master从任务/问题分支。
3. 当一个任务分支完成它的工作时，将其合并，integration看看它是否破坏了其他任务分支的任何工作。如果是，请修复它们。

4. 从任务分支（不是integration分支）拉取请求到master分支。

   这意味着该integration分支仅用于 CI 目的，它永远不会被合并到master

5. 决定下一个版本将包括哪些更改。将这些分支合并到master.
6. 发布。

这是问题所在，假设我有以下情况：

在F中，发生了两件事：

1. 发生合并冲突C并F更改了相同的行some-code.js
2. F打破了一些测试C。

现在，Bob 必须解决这个问题，他有两个选择：

选项1

1. 合并integration为bob/task#2_G
2. 修复中的错误H
3. 合并integration为I
4. integration绿色

5. 拉取请求

   /li>

但是，通过这种方法，我不能只task#2选择包含在我的下一个版本中。因为bob/task#2( H) 中已经包含了 中所做的更改ken/task#1，所以并入bob/task#2意味着master并入ken/task#1在一起master。

选项 2

1. 切换回bob/task#2
2. 尝试修复中的错误G
3. 合并integration并运行测试以查看测试是否为绿色
4. 如果没有，请切换回bob/task#2
5. 尝试修复它I

6. 合并integration并运行测试

   ...

   直到integration是绿色的。

7. 拉取请求

   /li>

这种方法可以防止将更改ken/test#1从bob/task#2.

然而，Bob 现在需要“猜测”他需要做什么来修复这个错误。然后一遍又一遍地合并到integration，看看测试是否是绿色的，因为G现在I没有添加测试C。

some-code.js每次他将他的工作合并到中时，他还需要解决同样的合并冲突integration，这既痛苦又多余。

Bob有更好的选择3吗？

谢谢。

我在 git 树中发生了一些意想不到的事情。我已经从 master 创建了一个分支，但是当我在新分支上执行提交时，看起来好像这些都发生在与 master 相同的代码行中......

如您所见，最左侧是 master 的代码行（深蓝色），在顶部右侧我们可以看到 Sprint_15，它是从 master 获取的一个分支，似乎在同一行上有提交......我我不确定为什么会这样。我希望看到代码分流成一个新行，因为功能正在合并到 Sprint_15 而不是主...

我的想法是，通过将 Sprint_14 和 Sprint_15 合并在一起，这对历史做了一些奇怪的事情，但我不知道为什么。

我对 git 还很陌生，所以它的一些基础仍然让我感到困惑。