问题标签 [branching-strategy]

我正在尝试使用 git 学习和开发最佳实践。关于分支，我一直在阅读 git flow 分支实践。基于这种做法，我的分支机构应该是

我使用本地仓库在本地机器上开发。我有两个要推送的远程裸仓库。一个是 TEST 服务器，第二个是 LIVE 生产服务器。这两个远程仓库都有一个接收后挂钩。

master 分支应该只保留给最终的生产代码。那么，我应该将哪个分支推送到 TEST 服务器？目前我必须将开发合并到主控，然后将本地主控推送到测试。但是，如果我在那次推送之后有任何编辑，那主人已经改变了，还没有真正准备好投入生产。我应该将开发分支推到测试服务器吗？然后，最终批准合并开发到主服务器，然后将主服务器推送到 LIVE 服务器？

我不明白为什么我对此感到如此困惑？我想我害怕犯任何错误。

背景

因此，我在上个月的大部分时间里都在使用 MSDeploy、SSDT 和 TeamCity 自动化我们的 web + db 部署。唯一的问题是，出于演示目的，我只在我们的主干分支工作。不用说，当您考虑需要进行并行开发工作（由 SVN 中的分支隔离）时，这种方法很快就会失败。这就是我卡住的地方，希望能找到一些帮助。

我们的情况

• 我们永远不必支持我们软件的多个并发版本
• 客户始终使用当前版本

我想出什么（到目前为止）

如我所见，我们实际上只需要源代码控制中的两个分支：

1. 当前： trunk - 部署发生的地方
2. Next：当前迭代的开发分支

在新迭代开始时，Current将被分支（让我们将该分支称为Next）。该迭代的所有开发都将提交给Next，同时，当前版本所需的任何错误修复都将提交给Current。在某个时刻，Next将“完成”，因此，合并回Current。

部署

就部署而言，Next永远不会部署到任何环境中。但是， Current将由 TeamCity 定期（每次提交、每晚等）自动打包/部署到内部环境。在某些时候，其中一个包会被认为“足够好”，因此会被推到部署流中（通过登台、生产）。

注意事项

鉴于上述过程，将Next合并到Current将保证Current上的“代码冻结” ，在此期间不能向客户发布新的错误修复。这种错误冻结将持续到Current被认为“足够好”以发布给客户端，此时Current将被标记并且整个过程将重新开始。

问题

1. 这种方法/思路合理吗？
2. 这种方法在哪里失败？
3. 有没有更好的方法来解决这个问题？

非常感谢任何见解/文档。

因此，假设您从 master 分支为您的应用程序创建一个“新功能 #101”。现在这个特性要等到 X 个月后（我们会说 3 个月）才会被推送到主服务器。在这 3 个月的时间里，假设我们分支了其他推送给 master 的特性，甚至一些 bug 修复直接给 master。自我们的“新功能 #101”以来，我们现在有一个包含 14 次以上提交的主分支。所以现在说它是 +3 个月和时间来推动“新功能 #101”，将其合并到 master 中的最佳方法是什么？我们是否直接合并到主服务器中，我们是否重新设置“新功能 #101”？正确的方法是什么？

开发人员开始开发一项功能，我们称之为“修复硬编码链接”，一旦完成，它就会传递给另一个开发人员进行同行评审。同行评审员对代码更改和将功能分支合并到测试分支没问题。“修复硬编码链接”现在在测试服务器上等待技术测试。

test是功能分支在经过其他开发人员同行评审后合并的staging地方，是功能分支通过同行评审、TT 和 UAT 后合并的分支。

下一位开发人员开始处理下一张卡片并创建一个如下所示的分支：

开发人员完成工作并将其传递给同行评审。同行审阅者对传递到 TT 和 UAT 的代码感到满意，所有人都很高兴并进入 PO。PO 很高兴，然后他将功能分支合并到 staging

通过这样做，我发现我们不仅应用了附加到特定卡修复程序的补丁，而且还应用了分支附带的整个历史记录。结果是提交“修复硬编码链接”正在暂存，但尚未完成该过程。

• 我们的方法有什么问题以及改进它的任何建议吗？
• 我们应该在 staging 之外创建我们的功能分支吗？

下面的 Git 分支模型似乎很普遍。 http://nvie.com/posts/a-successful-git-branching-model/

在我们当前的项目中，我们没有开发分支，并从 master 创建功能/错误修复分支并将它们合并回来并标记所有相关里程碑（完成功能/错误修复/发布）。

所以我想知道，拥有一个开发分支有什么好处？

我们有一个网络应用程序，我们有几个企业客户。我们最近决定将其作为 SaaS 应用程序提供并遵循精益方法（与我们的企业产品并行）。这意味着我们正在进行可能无法投入生产的实验。

在我们精简之前，我们对以下分支策略感到满意（我相信这是非常标准的）：

• 大师- 永远稳定
• dev - 通常不稳定（功能分支从 dev 中截断，以便新功能进入下一个主要版本）
• major_release_x - live（在 dev 合并到 master 后切断 master，这是修复错误并合并回 master 和 dev 的地方）

现在，除了上述内容之外，我们还有以下内容，但效果并不好：

• lea_release_branch - live（切断major_release_x并包含实验）
• Experiment_x - 切断major_release_x（这是我们将功能组合在一起然后将其合并到lean_release_branch的地方）

我们现在的情况是，我们需要按照精益方法的要求快速且经常地发布，当我们获得对任意事物的可靠反馈时，我们需要将其生产化并尽快发布（离开lea_release_branch）。

问题是我们不能从dev创建一个特性分支（因为它很可能是不稳定的）并且我们不能从lea_release_branch创建一个特性分支，原因有两个：

1. 它已被实验代码污染，因此此更改/功能将无法返回master
2. 精益发布分支总是需要准备好发布，所以如果有需要修复和发布的关键问题，我们不能忙于对其进行测试和修复（在将更改/功能合并到其中之后）

有人知道我们设置的更好策略吗？

我们想开始为新的iOS7版本做准备，但我不太确定如何在我们的 git 存储库中反映这一点。

我们需要开始更新 UI 并删除不推荐使用的方法，但我们不希望这些更改与我们当前的开发相混合。

同时，团队的一部分必须继续开发修复我们iOS6版本的功能。

我想到的第一个想法是创建一个新的远程分支“iOS7”，然后在我们必须交付 iOS7 版本时将它们合并，但是冲突会如此之多，以至于合并可能会令人头疼。

考虑到我们是一个小型开发团队，在这种情况下进行的最佳方法是什么？

情况：我见过一种实践，即从分支创建 SVN 分支并继续进行。例如： Branch1 是从 TRUNK 创建的；来自 Branch1 的 Branch2；等等。请参阅下文以获得一个想法：

....继续...... Branch4 --from --> Branch3 --from --> Branch2 --from--> Branch1 --from--> Trunk。

所以每个新分支都是从最新的分支创建的；而不是从 Trunk 或 Main 创建它。

问题：

1. 这种做法有错吗？
2. 这会导致问题吗？
3. 这种做法在任何地方都遵循吗？

更新：第一个和第三个问题有令人满意的答案。谢谢您的帮助。遵循此方法时，是否有任何需要特别注意的问题？

我在 clearcase 中的每个任务策略的分支存在问题。
我们正在使用快照视图。我们有各种任务分支和一个集成分支。
因此，我们将分支合并到集成进行测试。

现在，假设我正在处理一个BR1合并到集成分支的文件，并且该文件引用了另一个未合并到集成分支但BR2第二个文件合并到集成分支的文件。

因此，第二个文件指向文件的BR2版本，而我不想要这些更改，但由于我从集成分支中获取所有其他代码，因此它采用该版本。

这是我的配置规范：

有没有办法解决？我能想到的一种方法是放置一个标签，因此，将配置规范更改为从该标签中选择，而不是从最新的集成分支中选择，但是随着任务分支中工作的进展，这需要更改标签。还有其他方法吗我们能做到吗？

我有两个分支，A 和 B，它们都有一个文件 X。这些分支从一个代码库开始，但从那时起就相互交织合并，因为它们针对项目的不同实现进行了分支。X 已在 A 和 B 中更新。当我执行 git merge （使用默认递归策略）时，我得到一个合并冲突（无论我是将 B 合并到 A 中还是将 A 合并到 B 中），A 的文件版本具有已添加，而 B 的文件版本已被删除。

我已经使用 git 版本 1.8.2 使用 shell (Mac) 对此进行了测试。