e-receive腳本，通過執(zhí)行腳本中代碼，可以比較開發(fā)人員的本次提交和固定分支上上次提交的版本之間的差別，獲取到提交的文件路徑、文件操作等信息，再結(jié)合本次提交的版本號，添加提交人、時間等信息存儲在數(shù)據(jù)庫中，即認為本次提交的內(nèi)容獲取完成。
[0023]三、將Git中的版本轉(zhuǎn)換成自增編號存儲。
[0024]因為Git庫是使用全球唯一哈希碼作為版本號，哈希碼本身無法做大小的比較，所以為了方便在構(gòu)建的時候能做版本的大小比較，對每個提交到中央庫固定分支的哈希碼重新編號，編號采用自然數(shù)自增的方式，每提交一次編號加1，編號會和提交的哈希碼、文件路徑、文件操作等信息對應(yīng)，即一次提交中可能會包括多個文件，存儲在數(shù)據(jù)庫中。
[0025]四、開發(fā)的源代碼與任務(wù)包關(guān)聯(lián)。
[0026]為了精確構(gòu)建出能滿足某個需求或者解決某個bug所需的文件，需要區(qū)分開每個需求或者bug的完成涉及到的源文件，本發(fā)明在開發(fā)人員提交時，由開發(fā)人員定義任務(wù)包，任務(wù)包的基本信息中描述該包的作用，在開發(fā)人員開發(fā)完成后，中央庫接收到開發(fā)人員從本地庫提交的代碼時，將提交的代碼版本、版本編號、文件路徑、文件操作類型、提交人、提交時間等信息與任務(wù)包關(guān)聯(lián)，在構(gòu)建時，可以單獨構(gòu)建該任務(wù)包，精確取出完成需求或者解決bug需要的具體文件并構(gòu)建成升級包，可以不用為項目升級所有的文件，而只升級所涉及到的文件，將對項目生產(chǎn)環(huán)境的影響最小化。
[0027]五、隨時構(gòu)建并能獲取正確的文件版本。
[0028]當客戶的生產(chǎn)環(huán)境中出現(xiàn)問題后，一般希望開發(fā)人員立即解決并發(fā)布包修正問題，但是在常見的集成構(gòu)建中，要解決客戶的問題，需要構(gòu)建某個時間段的整個項目的程序，將整個項目的程序構(gòu)建成發(fā)布包，這個過程中，可能為了保證構(gòu)建環(huán)境的正確性需要等待相關(guān)的開發(fā)人員將代碼都提交后才能構(gòu)建，不能做到及時響應(yīng)客戶需求；而且可能包含對其他的問題的修正，如果不全面測試，升級后可能對客戶生產(chǎn)系統(tǒng)造成嚴重不良影響。為了達到有的放矢，本發(fā)明采用任務(wù)包將針對解決客戶問題的文件關(guān)聯(lián)起來，可以隨時構(gòu)建任務(wù)包。在協(xié)作開發(fā)的情況下，一個文件可能具有多個版本即版本編號存在多個任務(wù)包中，在構(gòu)建時，首先比較出本任務(wù)包中同一文件最大的版本編號，然后使用該文件的最大版本編號與該文件已經(jīng)構(gòu)建的版本編號比較，如果已經(jīng)構(gòu)建的版本編號比較大，則發(fā)布包中使用已經(jīng)構(gòu)建的最大的版本編號，否則使用任務(wù)包中的文件的最大版本編號，這樣保證了發(fā)布包中的文件版本不會覆蓋生產(chǎn)環(huán)境中的文件版本。
[0029]上述【具體實施方式】僅是本發(fā)明的具體個案，本發(fā)明的專利保護范圍包括但不限于上述【具體實施方式】，任何符合本發(fā)明的一種基于Git隨時發(fā)布代碼的實現(xiàn)方法的權(quán)利要求書的且任何所屬技術(shù)領(lǐng)域的普通技術(shù)人員對其所做的適當變化或替換，皆應(yīng)落入本發(fā)明的專利保護范圍。
【主權(quán)項】
1.一種基于Git隨時發(fā)布代碼的實現(xiàn)方法，其特征在于，其具體實現(xiàn)過程為: 一、首先管理員定義Git中央庫固定分支，即管理員定義某個Git資源庫為中央庫，并且指定項目的主干分支作為固定分支； 二、通過鉤子腳本獲取Git中央庫固定分支上代碼提交的最新版本； 三、將Git中的版本轉(zhuǎn)換成自增編號存儲； 四、將開發(fā)的源代碼與任務(wù)包關(guān)聯(lián)； 五、隨時構(gòu)建并能獲取正確的文件版本。2.根據(jù)權(quán)利要求1所述的一種基于Git隨時發(fā)布代碼的實現(xiàn)方法，其特征在于，所述步驟一中，管理員定義Git中央庫固定分支，開發(fā)人員創(chuàng)建任務(wù)包，開發(fā)人員在本地Git開發(fā)庫中開發(fā)代碼，開發(fā)完成后，與中央庫固定分支的代碼同步，解決沖突后將代碼提交到中央庫中。3.根據(jù)權(quán)利要求1所述的一種基于Git隨時發(fā)布代碼的實現(xiàn)方法，其特征在于，所述步驟二的具體過程為:在中央庫中添加鉤子腳本，監(jiān)控開發(fā)人員的每次提交，通過在鉤子腳本中比較開發(fā)人員的本次提交和固定分支上上次提交的版本之間的差別，獲取到包括提交的文件路徑、文件操作的信息，再結(jié)合本次提交的版本號，添加提交人、時間等信息存儲在數(shù)據(jù)庫中，即認為本次提交的內(nèi)容獲取完成。4.根據(jù)權(quán)利要求1所述的一種基于Git隨時發(fā)布代碼的實現(xiàn)方法，其特征在于，所述步驟三的具體過程為:Git庫使用哈希碼作為版本號，在存儲數(shù)據(jù)庫時，會自動為每個哈希碼定義編號，編號是自增的，構(gòu)建時以此編號作為比較依據(jù)。5.根據(jù)權(quán)利要求4所述的一種基于Git隨時發(fā)布代碼的實現(xiàn)方法，其特征在于，存儲數(shù)據(jù)庫時，對每個提交到中央庫固定分支的哈希碼重新編號的具體過程為:編號采用自然數(shù)自增的方式，每提交一次編號加1，編號和提交的哈希碼、文件路徑、文件操作信息對應(yīng)，即一次提交中包括多個文件，存儲在數(shù)據(jù)庫中。6.根據(jù)權(quán)利要求1所述的一種基于Git隨時發(fā)布代碼的實現(xiàn)方法，其特征在于，所述步驟四的詳細過程為:開發(fā)人員提交源代碼時，由開發(fā)人員定義任務(wù)包，任務(wù)包的基本信息中描述該包的作用，在開發(fā)人員開發(fā)完成后，中央庫接收到開發(fā)人員從本地庫提交的代碼時，將提交的代碼版本、版本編號、文件路徑、文件操作類型、提交人、提交時間信息與任務(wù)包關(guān)聯(lián)，在構(gòu)建時，單獨構(gòu)建該任務(wù)包，精確取出完成需求或者解決bug需要的具體文件并構(gòu)建成升級包。7.根據(jù)權(quán)利要求1所述的一種基于Git隨時發(fā)布代碼的實現(xiàn)方法，其特征在于，所述步驟五的詳細過程為:采用任務(wù)包將針對解決客戶問題的文件關(guān)聯(lián)起來，隨時構(gòu)建任務(wù)包；在協(xié)作開發(fā)的情況下，一個文件具有多個版本即版本編號存在多個任務(wù)包中，在構(gòu)建時，首先比較出本任務(wù)包中同一文件最大的版本編號，然后使用該文件的最大版本編號與該文件已經(jīng)構(gòu)建的版本編號比較，如果已經(jīng)構(gòu)建的版本編號比較大，則發(fā)布包中使用已經(jīng)構(gòu)建的最大的版本編號，否則使用任務(wù)包中的文件的最大版本編號，這樣保證了發(fā)布包中的文件版本不會覆蓋生產(chǎn)環(huán)境中的文件版本。
【專利摘要】本發(fā)明公開了一種基于Git隨時發(fā)布代碼的實現(xiàn)方法，其具體實現(xiàn)過程為：首先管理員定義Git中央庫固定分支，即管理員定義某個Git資源庫為中央庫，并且指定項目的主干分支作為固定分支；通過鉤子腳本獲取Git中央庫固定分支上代碼提交的最新版本；將Git中的版本轉(zhuǎn)換成自增編號存儲；將開發(fā)的源代碼與任務(wù)包關(guān)聯(lián)；隨時構(gòu)建并能獲取正確的文件版本。該一種基于Git隨時發(fā)布代碼的實現(xiàn)方法與現(xiàn)有技術(shù)相比，能夠在多人協(xié)作開發(fā)同一項目的情況下，不需要人工挑揀文件構(gòu)建，隨時構(gòu)建客戶需要的發(fā)布包，提高工作效率和發(fā)布包質(zhì)量，實用性強，適用范圍廣泛，易于推廣。
【IPC分類】G06F9/44
【公開號】CN105094851
【申請?zhí)枴緾N201510561172
【發(fā)明人】曲巖, 董金剛
【申請人】浪潮軟件股份有限公司
【公開日】2015年11月25日
【申請日】2015年9月6日