问题标签 [branching-strategy]

我的目标是有这样的结构：

理想情况下，在开发新功能时，我想分支“主”主干并创建一个新的“开发/功能 X”分支。一旦我准备好测试功能，我想使用合并工具将“功能 X”移动到“QA”。然后在完成并测试后从“QA”分支开始。一旦这是真的，我想从“QA”合并到“Main”。

这可能吗？我想在不进行毫无根据的合并的情况下做到这一点。我不确定如何构建分支以实现此解决方案。

我有以下情况：

一个内部服务器（server1），主 repo 有 2 个分支master和dev，四个开发人员有 3 个 git 克隆，使用dev的分支

规则：

1. 开发人员无法触及或合并 server1/master
2. 每个开发人员在工作前和推送前都需要更新 server1/master 的版本

我考虑了这个过程：开发人员 1 必须做：在git clone和也许git pull之后，每天都会是这样的：

修改后添加并提交：

在开发分支上测试后：

我想知道

1. 我的问题的最佳工作流程定义是什么
2. 每个开发人员的 git 命令是什么
3. 如果git pull是正确的或者最好有git rebase -i dev或者改变这个命令的位置

先感谢您

我们在 Visual Studio Team Foundation Server 中有两个单独的工件，一个用于源代码（分支），另一个用于数据库脚本（文件夹）。

分支是 - 3.0, 3.1, 3.2 ... 到 3-mainline，我们也有 4-mainline。

实际上 4-mainline (4.0) 已经发布，而我们也在开发 3.9（尚未发布）。有用于数据库脚本的文件夹 - 3.0_to_3.1、3.7_to_3.8、4.0 等，

问题是，假设我们实现了一个功能（对于 3.9 需要更改数据库），但该功能不适用于 4.0（因为 4.0 已经发布）。所以在将数据库从较低版本升级到 4.0 时，3.9 的脚本也将被执行（不应该）。

您能否在这方面向我推荐一个命名约定或任何相关的解决方案。

任何帮助表示赞赏。提前致谢

这个问题不是特定于 iOS 的，但为了清楚起见，我在此处包含了实际用例

我运行了一个名为 的 iOS 项目Foobar，显然处于版本控制之下。在 iOS 项目环境中的项目文件中，有一个名为Foobar-Info.plist的 XML 文件，它存储有关项目的有趣信息，例如版本和我所做的构建数量。

每次构建项目时，我都会增加存储在此文件中的构建计数，如下所示：

其中 '0.0.4-release' 是 git-flow 分支名称，2203 是内部版本号。这是在CFBundleVersion现场使用的，因此对我来说构建的来源非常明显。

想象一下，在另一个分支中，自发布以来我已经取得了很大的进步，并且相同的字段看起来像：

假设我完成了发布，它被合并到主线develop分支中。

问题

为了获得发布分支中所做的最新更改，我想将功能分支重新设置为develop.

发生这种情况时，Foobar-Info.plist将在变基过程中的每次提交时导致冲突。这是因为每次提交都会增加内部版本号；我必须通过选择行来手动合并，手动指定最新版本的行。请注意，三向差异的基本版本也将有所不同。

我如何告诉 git 对于一个特定的文件，Foobar-Info.plist我希望它通过进行最新的更改来为我解决冲突？

编辑：该文件必须保存在源代码控制之下。我想保留它，BuildCount因为它是我的项目投入努力的一个很酷的迹象，我想保留它！我知道这个数字只表示完成的最小构建数量，但这对我来说已经足够了。

我以前有 git 的经验，但是是 Subversion 的新手。我的任务是为我的团队建立一个存储库，但不确定最好的结构应该是怎样的。（建议我回到 git 在这里不起作用，因为我几乎被颠覆所困，但我感谢你的诚实建议！）

假设我的团队中有三个开发人员（Sam、Tom、Bob），他们每个人都需要自己的分支进行开发（并且他们提交到自己的分支，以便他们可以跟踪自己的更改和修订。我认为这是subversion 没有像 Git 那样的本地提交功能的解决方法。在 subversion 中提交相当于在 Git 中推送。）。之后，他们将更改推送到测试然后生产。这是我想到的结构：

这是工作流程：在一天结束时（或白天），所有开发人员从测试分支中提取更改，然后将更改推送到测试分支并在需要时解决冲突。对于生产更新，主干中的 MyProject将与Test 分支合并。

让我们假设开发人员将他们的更改定期推送到测试分支，以致合并的尝试不会导致灾难性的冲突。

问题：
1. 这是颠覆团队项目的良好结构吗？
2. 是否可以将开发者分支的根指向测试分支？所以当点击VisualSVN/Update时，开发者分支会自动更新到测试分支的头部。

在基于主干的开发分支模型中，您在主干上开发并从分支发布，每个版本都需要更新主干和新分支中的 POM 文件。

例如，如果将主干中的版本设置为 1.0-SNAPSHOT，则需要将发布分支更新为 1.0，主干更新为 1.1-SNAPSHOT。

我真的想要一种替代策略来排除更新主干上的版本的需要，以及与此相关的所有相关任务。考虑一下，您实际上不需要将版本号应用于主干。版本号仅在发布过程中真正变得相关，但 Maven（出于多种原因）需要版本号。

作为替代方案，我们可以将主干上的版本设置为 0.0-SNAPSHOT，这基本上表示特殊构建。但是，问题在于，就 Maven 而言，它会将其置于所有其他版本之前。

另一种方法可能是使用一些非常大的数字。这至少会在每个其他版本之后，如果主干代表您的开发的尖端，这是正确的。不过这感觉有点武断。

我能看到的唯一其他选项是使用字符串版本 - 例如 HEAD 或 LATEST，但这不符合最新的 Maven 版本控制方案。除了失去 SNAPSHOT 功能外，我相信整数版本将始终被认为比字符串更新（参见此处）。

所以，

1. 这个理论看起来合理吗？
2. 如果是这样，是否有更好的策略？

我一直在研究 gitflow 工作流程http://nvie.com/posts/a-successful-git-branching-model/，它是有道理的，并且与我过去所做的非常相似。在发布和热修复方面，我做了一些不同的事情，我想问一下 gitflow 分支方式与我提出的方式的优缺点。

通常，当我创建发布分支时，比如发布 1.0.0，我会将发布分支命名为 release-1.0.x，而不是 release-1.0.0。一旦我创建了分支（但在代码发布之前），版本将是 1.0.0-SNAPSHOT，用于任何最后一分钟的修复。当我发布时，我创建 1.0.0 的发布版本，标记它并合并到 master。现在我没有删除发布分支，而是将版本增加到 1.0.1-SNAPSHOT。这有效地成为了 1.0.x 系列的长期热修复分支。如果我在生产中发现错误，我会在这个分支上修复它，删除 1.0.1 发布版本并将版本增加为 1.0.2-SNAPSHOT，依此类推。

缺点是只要此版本是当前版本，发布分支就存在。好处是如果有错误，我不需要创建新的热修复分支，并且分支已经存在。

所以我的问题是我是否因为没有热修复分支并以这种方式这样做而遗漏了任何重大问题？

这是一个有趣的问题（或者至少我希望如此）。我一直在研究功能，并在 git 分支上进行了这些更改。

我需要创建对 master 的拉取请求（我已经重新设置了基础，我可以恢复），但是我的拼贴画抱怨拉取请求太大，应该在更多的拉取请求上拆分。

本质上，我需要将分支A上的提交拆分为分支B、C、D以获得更小的拉取请求。有人知道解决这个问题的好方法吗？

我想开始为我的团队使用 SVN，一个主干和每周发布分支进行测试并上线是我的想法。但是，有些项目在非特定时期之前不想上线。假设 1 月 1 日，团队开始对组件 A、B、C 和 D 进行更改。但是，到 3 月 1 日，组件 C 和 D 已包含在要到 8 月 1 日才会上线的项目中。我如何忽略所做的更改在 3 月 1 日至 8 月 1 日之间，组件 C 和 D 是否包含在发布分支中？特别是因为“功能标志”不能应用于这些代码，因为它不是自定义代码，而是现成的 oracle 代码？每周我还会想到主干、QA 分支和发布分支。团队将在 Trunk 中进行更改，他们在 Dev 分支上签入，一旦完成，他们就会提升/合并到 QA 分支。在 QA 分支测试后，它将由每周 Prod 发布分支发布。但是，有人告诉我，没有办法排除组件 C 和 D，因为 SVN 中的选择性合并。有什么想法吗？

让多个团队使用一个产品待办列表来开发一个产品，这些团队的每个成员经常将他们的代码提交到主干，而不是为每个团队设置分支是否是个好主意？

所以他们会在 Sprint 上单独工作，在代码审查后经常同步主干和他们的分支，然后首先将他们的工作代码添加到他们的分支中？

或者

我们可以使用什么方法，是否有任何标准模型？