最近在協助同事把負責的系統相關程式加入版控
花了一點時間理解該系統的相關程式、用途後,整理如下:
主要分成這三種類型,原則上就是有各式資料(格式不一),需要寫一堆ETL程式整理到DB
然後再提供一個界面讓USER查詢
在規劃Git Repository要怎麼開時,討論了三個想法:
我目前偏好方案1(個人習慣)
但發現滿多人其實想選方案2(覺得這樣比較簡單、直覺、查異動最快(同一個Repo))
註:目前使用的是微軟的解決方案 Azure DevOps Server(Local)
所以想詢問版上大神,以這樣的CASE來說,是否有建議的作法或是有踩過什麼坑可以提醒
謝謝
1.我投方案3一票
2.我覺得我們對一個「專案」的定義可能有所不同
應該我是說的說法問題,這裡的專案應該說是visual studio中有一個project. 目前是一個專案對應到一支程式的概念.(例如一種ETL程式)
如果一個程式的原始碼就有自己的Repository的話,會不會很難管理?
還是其實這樣做,其實很平常. ?
Git 只是工具
如何使用還是要看貴公司的人
來決定
試著先撇開 Git Repository 一下
想想:
為什麼原本那 40 個 ETL 的程式
是40
個專案而不是1
個專案
而那 40 個專案好不好管理
?
答案如何
就如何在 Git Repository 上依樣畫葫蘆就好了
40個ETL .Net程式專案要整合成一個
對他們的改變會太大. 但這確實是一個問題.
現在看到的現象是:
1.因為資料格式不同,沒辦法通用, 所以就另寫一支程式,專門處理.
2. 前人寫的,沒事不想動.
40個ETL .Net程式專案要整合成一個
對他們的改變會太大. 但這確實是一個問題.
現在看到的現象是:
1.因為資料格式不同,沒辦法通用, 所以就另寫一支程式,專門處理.
2. 前人寫的,沒事不想動.
一個.project對應一個Git
你如果要減少版本庫,應該是要從源頭去減少ETL的.project數
分開的好處是個別維護,減少merge與版本號的問題,也可以有不同的環境配置,但是40個確實很多,依照這種方式,以後可能是100或是200,所以應該要有一些分類規則出來
合併成一個ETL,好處是統一釋出的版本號管理,但是缺點就是多人同時存取單一專案時要合併的問題,但是維護一份Readme