关键词：
【中文标题】分支和合并策略【英文标题】：Branching and Merging Strategies 【发布时间】：2010-12-04 02:42:40 【问题描述】：我的任务是制定未来 6 个月的分支、合并和发布策略。
复杂性在于我们将运行多个项目，所有项目都有不同的代码更改和不同的发布日期，但开发开始日期大致相同。
目前我们正在使用 VSS 进行代码管理，但知道它可能会导致一些问题，并且会在新的开发开始之前迁移到 TFS。
在制定计划之前我应该采用哪些策略以及应该考虑哪些事情？
抱歉，如果这含糊不清，请随时提出问题，如果需要，我会更新更多信息。
【问题讨论】：
【参考方案1】：这是我遇到的最好的source control pattern。它强调了让后备箱没有任何垃圾（后备箱中没有垃圾）的重要性。开发应在开发分支中完成，定期合并（在测试代码后）应返回主干（图 1），但该模型还允许在开发过程中修补源代码（图 2）。我绝对建议您完整阅读这篇文章，以完全理解。
图一
图2
编辑：这些图片绝对是没有文字的混乱。我可以解释，但我基本上是在复制原作者。话虽如此，我可能应该选择一张更好的图片来描述合并过程，所以希望这会有所帮助。不过我还是推荐阅读这篇文章：
【讨论】：
我完全采用“后备箱中没有垃圾”来描述我们的 MAIN 分支。太棒了。 我会阅读这个，但我不会仅仅从图像中得到它，特别是如果你说：“后备箱里没有垃圾”。谁在测试主干？据我所知，这种模式正好相反，因为没有人主要将主干用于开发或测试...... @Quibblesome - 模式表示它必须在合并到主干之前适合发布，并强烈建议合并后分支和主干将相同..【参考方案2】：我见过的最简单和最常用的分支工作方式是在两个前提下进行。主干和释放。我认为这就是所谓的“不稳定的主干，稳定的分支”理念。
Trunk 是您的主要来源。这包含“最新和最伟大”的代码并且具有前瞻性。它通常并不总是稳定的。
Release 是与主干的一对多关联。有一个主干，但有许多从主干派生的版本。一旦特定功能里程碑被击中，发布通常从主干的一个分支开始，因此对于特定部署剩下的“唯一”事情应该只是错误修复。然后分支主干，给它一个标签（例如 1.6 版本是我们当前的最新版本），构建并将版本发送给 QA。此时，我们还将主干的版本号（通常是次要版本号）向上推，以确保我们没有两个版本号相同。
然后您在发布分支上开始测试周期。当进行了充分的测试后，您将错误修复应用到发布分支，将它们合并回主干（以确保错误修复被继续执行！），然后重新发布分支的构建。这个 QA 循环一直持续到您都满意并且最终将版本提供给客户。来自客户的任何准确的错误报告（即它们是错误！）开始与相关分支的另一个 QA 周期。
在您创建未来的版本时，最好尝试将老客户转移到新的分支上，以减少您可能需要将错误修复补丁修补到其中的潜在分支数量。
使用此技术，您可以将使用您的技术的解决方案部署到需要不同服务级别的各种客户（从至少优先开始），您可以将现有部署与主干中的“危险”新代码和最糟糕的合并隔离开来场景是一个分支。
【讨论】：
【参考方案3】：我的第一个建议是阅读 Eric Sink 的 Source Control HOWTO - 特别是 branches 和 branch merge 章节。
我们有 3 个容器 - DEV、MAIN 和 RELEASE 用于我们的工作。 MAIN 包含我们所有的“准备发布”代码，我们倾向于认为它是“基本稳定的”。 DEV/Iteration（或 DEV/Feature，或 DEV/RiskyFeatureThatMightBreakSomeoneElse）是 MAIN 的分支，并在 Iteration/Feature 准备好升级到 DEV 环境时合并。我们还从 DEV/Iteration 分支和 MAIN 分支设置了 TFS 构建。
我们的 RELEASE 容器包含编号的版本（类似于许多 Subversion 存储库中使用的“标签”容器）。我们每次都只是从 MAIN 中获取一个分支 - 我想说我们正在“剪切”一个 RELEASE 分支，以表明一旦合并完成，这不应该有很多活动。
至于 VSS->TFS - Microsoft 支持upgrade path，应该保留您的版本历史记录，但如果您不需要历史记录，我会从 VSS 获取最新版本，将其检入 TFS 并存档 VSS 存储库。
最后一个提示 - 让您的团队成员熟悉源代码管理。 他们必须了解分支和合并，否则您将陷入大量清理工作:)。
祝你好运！
【讨论】：
【参考方案4】：颠覆书描述了some common branching patterns。也许您也可以将这些应用到 TFS。
【讨论】：
只更改空格的合并策略？
...es?【发布时间】：2012-03-0420:31:20【问题描述】：我在master分支中做了一个代码格式。它主要修复了空格问题，例如：格式化制表符空间长度，在大括号前后添加和删除换行符。问题是，当我尝试从其他分支合并master时，我遇到了... 查看详情
git入门：创建合并分支解决冲突分支管理策略
分支创建与合并理解：相当于创建多一个与现在一模一样的平行时空在这基础上继续干活但其实并不会影响到当前时空，合并时再决定A时空并入B时空还是B时空并入A和空查看分支gitbranch;创建分支gitbranch‘分支名‘切换分支gitchec... 查看详情
你啥时候会使用不同的 git 合并策略？
...策略。解决-这只能使用3路合并算法解决两个头（即当前分支和您从中提取的另一个分支）。它试图仔细检测交叉合并歧义，通常被认为是安全和快速的。递归- 查看详情
git分支管理分支管理策略不使用fastforward模式进行合并(代码片段)
通常，合并分支时，如果可能，Git会用Fastforward模式，但这种模式下，删除分支后，会丢掉分支信息。 如果要强制禁用Fastforward模式，Git就会在merge时生成一个新的commit， 这样，从分支历史上就可以看出分支... 查看详情
查找未合并的 Git 分支？
】查找未合并的Git分支？【英文标题】：FindunmergedGitbranches?【发布时间】：2012-08-2920:26:53【问题描述】：我有一个包含许多分支的Git存储库，其中一些已经合并，有些没有。由于分支的数量很大，如何确定哪些分支尚未合并？我... 查看详情
git分支管理策略
Git分支管理策略 如果你严肃对待编程，就必定会使用"版本管理系统"（VersionControlSystem）。眼下最流行的"版本管理系统"，非Git莫属。相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge... 查看详情
git学习6--分支管理策略，bug分支
1.准备合并dev分支，请注意--no-ff参数，表示禁用Fastforward：$gitmerge--no-ff-m"mergewithno-ff"devMergemadebythe‘recursive‘strategy.readme.txt|1+1filechanged,1insertion(+)合并后，我们用gitlog看看分支历史：$gitlog--graph--pretty=onelin 查看详情
如何在 Azure DevOps 中删除合并的功能分支？
】如何在AzureDevOps中删除合并的功能分支？【英文标题】：HowtoremovemergedfeaturebranchesinAzureDevOps?【发布时间】：2020-12-0123:24:05【问题描述】：我们曾经在拉取请求中自动删除功能分支。但是后来我们需要向功能分支添加分支策略，... 查看详情
git分支管理策略
在项目中推荐的Git分支管理策略介绍：主分支Master永久分支首先，代码库应该有一个、且仅有一个主分支Master。项目的正式版本，都在这个主分支上发布。它是自动建立的，版本库初始化以后，默认就是在Master分支进行开发。功... 查看详情
Git 在将两个分支合并到主（主）分支之前将一个开发人员分支合并到另一个开发人员分支
】Git在将两个分支合并到主（主）分支之前将一个开发人员分支合并到另一个开发人员分支【英文标题】：GitMergingonedeveloperbranchtoanotherdeveloperbranchbeforemergingbothbranchestomaster(themain)branch【发布时间】：2021-11-1313:59:40【问题描述】... 查看详情
gitflow分支管理策略(代码片段)
Gitflow存在两个记录项目历史的分支Master分支：存储（官方的，正式的）项目发布历史记录的分支。develop分支：充当功能的集成分支。Develop分支将包含项目的完整历史记录，而master将包含简化版本。现在，其他开发人员应该克隆... 查看详情
git工程开发实践——git分支管理策略(代码片段)
Git工程开发实践（四）——Git分支管理策略一、Git版本管理的挑战Git是非常优秀的版本管理工具，但面对版本管理依然有非常大得挑战。工程开发中，开发者彼此的代码协作必然带来很多问题和挑战：A、如何开始一个Feature开发... 查看详情
gitmerge和rebase的区别
...gitrebase--continue继续，或者--skip跳过（注意此操作中当前分支的修改会直接覆盖目标分支的冲突部分），亦或者--abort直接停止该次rebase操作merge--no-ff与merge--ff-only的区别上面对merge的讲述都是基于其默认操作即--no-ff（gitmergexxx=gitme... 查看详情
分支策略 GIT [关闭]
】分支策略GIT[关闭]【英文标题】：BranchingStrategyGIT[closed]【发布时间】：2021-07-0212:23:00【问题描述】：我们正在进行基于功能的开发，一旦PR获得批准，它就会合并回master。当master的上线功能稳定时，我们会创建一个release分支。... 查看详情
svn分支管理策略个人见解
本篇目录前言SVN分支管理策略VisualSVNServerTortoiseSVN客户端Repository的创建Checkouttrunk创建新项目MyProjecttrunk更新提交更新，迭代版本创建TagV1.0基于Tag的HotfixBranchHotfixBranch改动Marge(合并)到trunk中同时创Tag_V1.1进行发布定制化分支Customize... 查看详情
git----分支管理之分支管理策略04
通常，合并分支时，如果可能，Git会用Fastforward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fastforward模式，Git就会在merge时生产一个新的commit，这样，从分支历史上就可以看出分支信息。下面我们实... 查看详情
[廖雪峰]git分支管理策略
通常，合并分支时，如果可能，Git会用 Fastforward 模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制 禁用 Fastforward 模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支... 查看详情
svn分支的合并和同步
SVN分支的合并和同步使用svn几年了，一直对分支和合并敬而远之，一来是因为分支的管理不该我操心，二来即使涉及到分支的管理，也不敢贸然使用合并功能，生怕合并出了问题对团队造成不良影响，最主要的原因是，自己对分... 查看详情