Git相關介紹

搜狗測試2019-06-26 02:33:19

背景

搜狗輸入法開發同學在近期將輸入法代碼整體遷移到了公司內部的Git服務器,方便多分支管理。遷移後,測試對開發代碼如何拉分支、如何查看changelog、如何打包、如何進行持續集成測試等等工作就產生了一些問題,也希望能做到知己知彼更好的保證質量,所以在此,小編梳理了一下Git相關的信息供測試同學瞭解。

Git是什麼,為什麼從SVN遷移到Git?

Git就是一個免費託管開源代碼的遠程倉庫,你可以理解它就是一個大型文件服務器,在上面放置了N多代碼文件。同時,Git還有一個web頁面,可以方便用户訪問、操作代碼。

 

很多關於 Git 的文章都會説 Git 是分佈式的,比 SVN 那種集中式的管理更安全。還有一種説法是,可以在火車上 Commit 代碼。

我的疑問是:SVN 之所以集中管理,一定程度上是需要避免代碼的衝突,而 Git 這種所謂的離線提交,等到聯網 push 的時候不是也會衝突嗎?從這個角度來看,離線與在線提交都會產生代碼衝突,那為什麼 Git 就好,SVN 就不好呢?


1、git有強大的分支管理能力

分支是什麼:

在 SVN這類的版本控制系統上,分支(branch)是一個完整的目錄,且這個目錄擁有完整的實際文件。如果工作成員想要開啟新的分支,那將會影響“全世界”!每個人都會擁有和你一樣的分支。如果你的分支是用來對系統模塊進行安全檢查測試的,那將會像傳染病一樣,你改一個分支,還得讓其他人重新切分支重新下載,而且這些代碼很可能對穩定版本還是具有破壞性的。

在Git上,每個工作成員可以任意在自己的本地版本庫開啟無限個分支。舉例:當我想嘗試破壞自己的程序(安檢測試),並且想保留這些被修改的文件供日後使用,我可以開一個分支,做我喜歡的事。完全不需擔心妨礙其他工作成員。只要我不合並及提交到主要版本庫,沒有一個工作成員會被影響。等到我不需要這個分支時,我只要把它從我的本地版本庫刪除即可,無痛無癢。

我可以在Git的任意一個提交點(commitpoint)開啟分支!(其中一個方法是使用gitk –all 可觀察整個提交記錄,然後在任意點開分支。)



2、git是分佈式的、支持離線工作

但是集中式的版本控制,有個嚴重的缺陷。就是中央服務器的單點故障。如果服務宕機一個小時,在這期間,沒有任何人可以在正在工作的版本上很好的合作或者去保存某一個版本的改變。另外如果中央數據庫的磁盤壞了,並且可能沒有保存備份,那麼將丟失所有的東西。你失去了絕對一切 - 除了單一的任何人的快照恰好有在本地計算機上項目的整個歷史。當然本地的版本控制系統也有相同的問題。雖然,你能夠把每個人的本地代碼,進行合併得到一個相對完整的版本,但是當你把這個相對完整的版本重新部署到服務器的新倉庫時,將會丟失所有的歷史版本包括日誌。

在Git 中的絕大多數操作都只需要訪問本地文件和資源,不必聯網就可以看到所有的歷史版本記錄,而SVN 卻需要聯網。因為 Git 在本地磁盤上就保存着所有當前項目的歷史更新,所以處理起來速度飛快,但我們需要瀏覽項目的歷史更新摘要,Git 不用跑到外面的服務器上去取數據回來,而直接從本地數據庫讀取後展示給你看。如果想要看當前版本的文件和一個月前的版本之間有何差異,Git 會取出一個月前的快照和當前文件作一次差異運算。

 

SVN 斷開網絡或者斷開VPN就無法commit代碼,但是Git 可以先commit到本地倉庫。用SVN的話,沒有網絡或者斷開VPN時,你當然也可以繼續在本地開發,但是無法commit代碼,因為SVN 每次commit都必須聯網,長時間不commit代碼會丟失大量開發進程的歷史紀錄。有個比喻是:不能commit就像用word寫文檔不能save一樣危險。而且有網絡的情況下每一次commit都會花上數秒甚至更長時間。但用 Git 的話,就算你在飛機或者火車上,都可以非常愉快地頻繁提交更新,因為是在本地倉庫commit所以幾乎不需要時間,而且commit一定要頻繁,不然無法記錄你的改動,如果你一天commit一次,中間的修改你就找不回來,然後等到了有網絡的時候再將版本紀錄和代碼一起上傳到遠程倉庫。

 

Git 的內容完整性要優於SVN。因為Git 在commit(存儲在本地)或者push(上傳到遠程倉庫)之前,通過對文件的內容或目錄的結構計算出一個 SHA-1哈希值,作為指紋字符串進行內容的校驗,並將此結果作為數據的唯一標識和索引,在遠處倉庫接受到commit的文件之後,會再計算一遍哈希值然後跟傳遞過來的哈希值做比較,如果不一致,説明文件在傳輸時變得不完整,或者磁盤損壞導致文件數據損壞。另外在 Git 數據庫中的東西都是用此哈希值來作索引,而不是靠文件名。


3、git更快

Git 克隆一個完整項目的速度非常快,SVN 非常慢。我們以克隆一份擁有五個分支的完整項目以及版本庫來説,SVN是同時複製5個版本的文件,也就是説重複五次同樣的動作。而Git 只是獲取文件的每個版本的元素,然後只載入主要的分支(master)在我的經驗,克隆一個擁有將近一萬個提交(commit),五個分支,每個分支有大約1500個文件的 SVN,耗了將近一個小時!而Git只用了區區的1分鐘。

 

4、git 的缺點

Git 沒有嚴格的權限管理控制,一般通過系統設置文件讀寫權限的方式來做權限控制;

工作目錄只能是整個項目。比如 checkout,建分支,都是基於整個項目的。而 svn 可以基於項目中的某一個目錄;代碼保密性差,一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本信息。

Gerrit又是什麼?

https://git.XXX.com/XXXX

Git遠程倉庫,用來備份輸入法代碼,一般不對這個倉庫進行操作。

http://gerrit.XXX.com

Gerrit是一個免費、開放源代碼的代碼審查軟件。利用網頁瀏覽器,同一個團隊的軟件程序員,可以相互審閲彼此修改後的程序代碼,決定是否能夠提交,退回或者繼續修改。Gerrit 是使用 Git 作為底層版本控制系統,通過網頁界面,能方便的做代碼審核工作的一個輕量型框架,出自google團隊的開源項目。其主要功能就是用來做Code Review。可以用自己的公司賬號登錄,開發負責加相關代碼權限。Web頁面,攔截push代碼操作,實現代碼Review,同時實現相關權限管理。

開發怎麼用Git?

按照需求提出後的開發順序一般分為以下幾步:

一、開發拉分支

1.拉分支時機是什麼?(原計劃是上一條支線A上線後,在A支線基礎上拉出,但目前迭代較快,不能實現在前一條支線完全上線後再拉取下一條支線進行開發。)

Answer:如下圖所示,V8.36在測試階段,V8.37會基於V8.36集成測試後的版本拉分支,當V8.36上線後有bug修復,會有機制通知對應開發把修復bug代碼Merge到V8.37功能分支上。

2.拉分支命令Git branch?有沒有其他方法?拉好後如何通知其他開發拉功能分支?

Answer:目前大部分開發通過Android studio選到某一分支,通過New branch拉分支。

開發同學在新功能開發前會主動找開發負責人口頭確認。

3.如果B開發的功能依賴A開發的功能,如何拉分支?

Answer:功能分支的拉取,都必須基於上一條發版分支拉取,即都基於上圖的V8.36上拉分支,如果有依賴的函數,可以通過Merge來操作。不允許出現B功能從A功能支線上拉取分支的現象出現。


二、開發實現,提交代碼

功能開發會先提交代碼到本地倉庫,然後提交到gerrit倉庫等待代碼review,通過Gerrit的權限控制不會把代碼提交到遠程Git倉庫。


三、解決衝突,Merge/合併代碼

1.解決衝突的時機?

Answer:必須在代碼Merge到Gerrit的時候解衝突,比如push 語音分支代碼  to V8.31分支的時候,會先拉取最新V8.31分支代碼到本地,解決語音分支代碼和V8.31代碼的衝突後才可以提交代碼到gerrit。

2.Merge代碼到發版支線的時機是什麼?令牌機制怎麼生效的?(解決多個開發同時Merge代碼會導致混亂的情況。)

Answer:

令牌機制解釋:

①測試完成後,會通過郵件通知開發哪些功能分支通過測試,可以進行Merge到發版分支的操作;

②開發負責人根據測試郵件,會通過打包系統的代碼凍結功能,逐一開放對應開發Merge功能分支代碼到發版分支的權限,類似令牌傳遞。

3.會不會存在開發隨意/不小心merge到發版分支的情況?

Answer:不會。發版分支在測試階段會凍結,直到測試通過進入到集成測試階段後解凍。Merge只能在解除凍結後進行。


四、代碼Review

1.Review是否強制執行?Review log可以看到嗎?比如是不是每筆代碼都經過了review。

Answer:Review機制強制執行,不review無法進gerrit。可以通過gerrit上的面板查看review log。以下是gerrit系統review面板截圖:


五、打包(dailybuild包, 灰度包、正式版包、實驗版包)

1.如何打包(測試包,灰度包,正式版包,實驗包)

Answer:均可通過打包系統自動打包。打包前需要進行相關配置,如下圖所示:


六、bug修復

1.發現的Bug在什麼支線修復?

Answer:功能測試階段發現的Bug在功能支線上修復,合併功能支線之後在集成測試過程中發現的bug在合併後的分支上修復。


七、版本發佈/上線後的支線操作

1.上線後,支線做什麼處理?是否會凍結?

Answer:灰度期間不做凍結,方便開發修復Bug,在正式版發佈後對發版支線進行凍結,並Merge代碼到Master支線進行備份。

2.上線後發現bug怎麼修復?

Answer:在發版分支上修復,並重新打包release分支進行發版。

3.如果發現歷史bug,怎麼在以前的支線上修復並Merge?

Answer:不需要在以前支線修復,在最新待發版的支線修復,可能在功能分支上,可能在發版分支上。

測試怎麼用Git

怎麼Clone和查看輸入法代碼?

推薦Git GUI工具Source Tree:https://www.sourcetreeapp.com/

公司的Gerrit倉庫可以通過公司郵箱登錄,所以在source Tree的授權過程中,也使用公司郵箱。(郵箱相關的權限需要申請。)

具體工具的使用大家可以自行搜索,在此不多贅述。

遷移時發現的問題

一、遷移是通過SVN的命令 SVN Git實現的,但是這個命令會自動排查空的文件夾並去除,影響到了輸入法模塊的邏輯。

解決方案:通過自動化腳本對比SVN和Git所有的代碼文件並進行MD5check,對被過濾掉的文件進行測試,保證功能不受影響。

歡迎添加我們的搜狗測試微信號,與我們一起聊聊測試。


https://hk.wxwenku.com/d/201004012