關(guān)于項(xiàng)目使用 Merge Requests 進(jìn)行代碼質(zhì)量管理的說明

一、目的

?1. 提高全體綜合技術(shù)水平，加快產(chǎn)品開發(fā)進(jìn)度，保障產(chǎn)品質(zhì)量。

?2. 促進(jìn)每個(gè)人的個(gè)人成長(zhǎng)，技術(shù)成長(zhǎng)，項(xiàng)目工程化水平。

?3.?增進(jìn)技術(shù)交流，倡導(dǎo)技能競(jìng)爭(zhēng)精神。

二、手段

?1.使用?gitlib 的 MR?功能。功能開發(fā)完成后，向測(cè)試主分支合并代碼時(shí)，使用合并請(qǐng)求，評(píng)審人評(píng)審并通過后，才可合并到測(cè)試主分支。

?2.?各項(xiàng)目采取技術(shù)負(fù)責(zé)人制，提高技術(shù)負(fù)責(zé)人的全局代碼參與度。由前后端技術(shù)負(fù)責(zé)人 Review?項(xiàng)目成員（可以是一個(gè)人），并在 git 系統(tǒng)內(nèi)進(jìn)行 MR (Merge ReQuests)?管理。

?3.?相在的代碼規(guī)范由 UEA 技術(shù)組起草制定，全體成員一起升級(jí)維護(hù)。

三、流程

?1. 項(xiàng)目代碼庫設(shè)置主分支，測(cè)試分支。

?2. 每個(gè)人在自己分支下開發(fā)完成后，向測(cè)試分支提交合并請(qǐng)求。

?3. 由技術(shù)負(fù)責(zé)人或項(xiàng)目自由指定的 Code Review?負(fù)責(zé)人審核代碼，不符合規(guī)范要求、技術(shù)選型、存在技術(shù)問題等各種情況，在 Git 系統(tǒng)進(jìn)行反饋，并駁回。

?4. 開發(fā)人員再次完善修改代友，并提并代碼后，重新提交“合并請(qǐng)求”。

?5.?Code Review?負(fù)責(zé)人再次審核，選擇通過合并，或反饋意見。

四、差異評(píng)判

1.?項(xiàng)目成員如果有對(duì)負(fù)責(zé)人評(píng)審不認(rèn)可情況，可交由 UEA 技術(shù)組和技術(shù)人溝通確認(rèn)。采取以理服人的辯論方式。

2. 代碼規(guī)范相關(guān)的問題由 UEA?解答，如果編碼規(guī)范不全時(shí)完善代碼規(guī)范。技術(shù)問題采取多方論證，力求共同找到最優(yōu)方式。

3.?其它 UEA?技術(shù)組參與仍然不能解決的情況。邀請(qǐng)各項(xiàng)目組相關(guān)技術(shù)一起投票決定。

五、獎(jiǎng)罰機(jī)制

對(duì)于在互聯(lián)網(wǎng)行業(yè)耕耘的 軟件工程師，

學(xué)會(huì)思考是對(duì)其個(gè)人最大的獎(jiǎng)勵(lì)。

需要驅(qū)動(dòng)其學(xué)習(xí)和成長(zhǎng)，也許算是一種懲罰。

uea關(guān)于merge request的規(guī)范：

commit原則：

? 1? 完成一個(gè)頁面、功能時(shí)；或者當(dāng)天下班提交一次；

? 2? 必須有相關(guān)備注，未完成的提交可以加個(gè)前綴，如 【temp 訂單列表】

? 3? 復(fù)雜的、修改內(nèi)容較多的bug commit一次。

為使merge request更有意義，原則如下：

? 1? 新功能開發(fā)階段，可以在初步完成一個(gè)頁面、功能時(shí)進(jìn)行merge request。

? 2? 不要積壓很多功能再M(fèi)R，會(huì)增加review復(fù)雜度。

? 3? 描述MR包含內(nèi)容，功能點(diǎn)等