各位ABAP公民們、特别是使用abapGit的各位，你們好。
我的團隊和我将向大家分享我公司内引入abapGit後産生的某些開發問題。我所在的公司是一家創作SAP第三方軟體的公司，目前主要使用ABAP和UI5。
本文專門針對ABAP方面。
首先，我們愛abapGit，相信你們中的很多也是一樣...
GitHub repository
我們的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工作台上面看到這個，但是，你仍然有可能沒看到它。
-
場景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簡介