abapGit分支策略
各位ABAP公民们、特别是使用abapGit的各位，你们好。
我的团队和我将向大家分享我公司内引入abapGit后产生的某些开发问题。我所在的公司是一家创作SAP第三方软件的公司，目前主要使用ABAP和UI5。
本文专门针对ABAP方面。
首先，我们爱abapGit，相信你们中的很多也是一样…
我们的git仓库使用GitLab托管在本地，有着各种用户友好的特性。
我们至少每天push一次我们的commit，生成版本（可以说是一个额外的备份层）。
通过使用GitLabs的代码审查功能，也使代码审查变得容易了许多。
我们最近评估了使用分支的可能性，得出的结论是：我们不能在现有的基础设施之上使用它。
本文的剩余部分将探究如何使用abapGit实现分支。
本文链接：http://www.cnblogs.com/hhelibeb/p/7754487.html
英文原文：abapGit Branching Strategy Discussion
场景1：无分支
这就是我们现在的工作方式。所有开发者在相同的SAP系统和代码基础（code base）上工作，所有人都push代码到主“分支”上。
优势
- 更好的代码版本控制
- 易于进行代码审查
劣势
- 分支是不可能的，开发者同时在同样的代码基础上修改对象
- 切换分支时，会改变每个开发者的代码基础，虽然他们也许会以为自己还在他们的分支上
- 代码会因为其他人的问题commit出错
- 甲修改了对象A，乙后来也修改了它
甲在不知道乙修改过A的情况下进行了commit - 是的，进行最后一个修改的人可以在abapGit工作台上面看到这个，但是，你仍然有可能没看到它。
- 甲修改了对象A，乙后来也修改了它
场景2：使用分支
无法马上使用分支的根本原因在于，所有开发者使用同样的代码基础。开发者没有隔离他们同事的代码修改行为。
所以，实现真正分支的第一步就是，分割每个开发者的开发环境。这意味着，每个开发者要有他自己的SAP系统来进行开发。
这带给我们第一个整体的不利条件：
- 开发者数量的增加带来的高昂的维护费用。
Local VMs
我们的第一个想法是，为什么不在开发者的机器上虚拟化运行SAP系统呢？
开发者在进行一项任务时，可以push到他们的分支当中，直到它们创建一个merge request。
主开发系统（DEV）只从主分支拉取，主分支只包含被批准的merge request。
优势
- 连接到你的SAP系统时，不需要网络接口
- 你可以在不连接公司网络的情况下开发
- 只需要在push代码到git仓库的时候才需要连接公司网络
- 在SSD上面运行SAP系统真的快极了
劣势
- 高维护开销
- 管理员对机器的控制比较难
- 开发者需要知道怎样开启/关闭他们的虚拟机/SAP系统
- 甚至可能需要他们自己定时备份虚拟机
某些总体问题也打击了我们：
升级开发者的SAP系统
- 如何给系统打补丁（支持包，notes，系统级补丁）？
- 当需要获取定制数据、主数据和业务数据来开发新特性、重现bug并且修复时，要怎样获取它们？
升级主开发SAP系统
- 如何处理abapGit不能序列化的开发对象？
- 当需要获取定制数据、主数据和业务数据来开发新特性、重现bug并且修复时，主开发系统要怎样获取它们？
- 从主分支拉取代码后，要如何处理开发对象以把它们分配到合适的传输请求之上？
- 也许你有个复杂的传输规则以帮助代码复用。我们就是如此。
你还需要一个策略来应对以下问题：
- 为无法序列化的对象单独维护和配置以及单独地导入定制和工作台传输
- 听起来像一团糟
- 开发系统的复制（只复制SAP）
- 只是为了给你定制数据
- 克隆主开发系统运行的虚拟机（OS+SAP）
- 并且重命名SID和全称域名（Full Qualified Domain Name），否则你会遇到网络问题
- ……
并且，更新的频率是？
- 按需
- 在创建一个新分支前
- 在一个新的发布循环开始的时候
- ……
Hosted VMs
升级看起来是个大问题，也许不用一个本地虚拟机、而是使用托管虚拟机会更好。
这样的话，无论采取何种策略来更新，都可以更轻松地执行。
优势：
- 管理员可以在任何时间访问机器
劣势：
- 运行开发虚拟机带来的托管成本
结论
所以，进行这一切的优点是什么？
我们的看法是：
- 真正的分支成为可能，编码时不干涉其它开发者
- 由于merge request和多个commit的结合，更加有利于代码审查
- 对多个发行版本的良好支持，容易切换到一个发行分支上去
- ……
值得为此做出很多的努力吗？
我们的团队并不知道答案。系统同步带来的成本，看起来是巨大的。
在这点上我们感到不舒服，因此转向社区，希望听到你们在这个话题上的的意见和经验。
非常感谢，
André
参考文章：abapGit简介