android自用規(guī)范三:git篇

分支命名

origin/master

和線上代碼一致,隨時(shí)可以切出打熱修復(fù)補(bǔ)丁

origin/develop

開(kāi)發(fā)主干分支

release_功能名(版本名)

功能主干分支

feature/功能名_模塊名

功能子分支,開(kāi)發(fā)完成后,發(fā)起pr到功能主干分支,通過(guò)后刪除此分支,因此存活時(shí)間為1~2天

hotfix_bug名(版本名)

修復(fù)bug分支,一般從master切出,打完熱修復(fù)立刻合并到master分支。

PR提交規(guī)范

目的:通過(guò)降低審核者的閱讀門檻,提高pr的審核效率,從而保證項(xiàng)目的開(kāi)發(fā)進(jìn)度。

  1. PR的顆粒盡可能小,基于一個(gè)小功能(開(kāi)發(fā)時(shí)間4h以內(nèi)),標(biāo)題要寫明pr目的

  2. PR備注必須聲明1:修改點(diǎn) 2:影響范圍

    pr描述

  3. PR除了添加審核人之外,如果多現(xiàn)有代碼邏輯上有修改的,則同步@現(xiàn)有代碼作者

  4. 在提交PR,告知參與人之后,可以繼續(xù)開(kāi)發(fā),后續(xù)代碼推送到新分支。審核者有意見(jiàn)需要返工修改時(shí),再?gòu)膒r分支切出來(lái)統(tǒng)一修改

分支職責(zé)

  1. master分支,能切出來(lái)打hotfix
  2. develop分支,優(yōu)化、修改的點(diǎn),和迭代的業(yè)務(wù)功能沒(méi)關(guān)系(改動(dòng)可以合并進(jìn)各個(gè)feature)
  3. feature分支,獨(dú)立的功能分支,從develop分支切出,不和其他迭代代碼污染(不合并release分支)
  4. release分支,要發(fā)布版本的分支,合并了develop分支、各個(gè)feature分支

操作步驟

  1. 主管建分支
    主管新建分支 feature、hotfix ,分支任務(wù)工作量0.5-1個(gè)工作日,每個(gè)commit的代碼修改目的清晰
  2. 組員切分支
    組員從分支切出,如果該分支就一人負(fù)責(zé)(分支名已經(jīng)描述了要做的事兒),則遠(yuǎn)程分支添加后綴-review;多人共同開(kāi)發(fā)的,則添加后綴-功能名

-功能名

  1. 開(kāi)發(fā)完自審
    開(kāi)發(fā)完成,自測(cè)沒(méi)問(wèn)題后準(zhǔn)備提交,先依次自己回審Commit Changes里的文件、排查是否有IDE提示

    android studio 圖形化commit界面

  2. 發(fā)起代碼回審
    發(fā)起后,在im上通知審核人

    image.png

  3. code review
    代碼回審發(fā)現(xiàn)問(wèn)題,通過(guò)評(píng)論的方式指出,一波結(jié)束后,在im上通知發(fā)起人。

    TIM截圖20180510170256.png

  4. 結(jié)束代碼回審
    問(wèn)題改完后,審核人合并pr,結(jié)束后,發(fā)起分支自動(dòng)被刪除,代碼合并到目標(biāo)分支。

舉個(gè)例子:

單人開(kāi)發(fā)
挑戰(zhàn)結(jié)果頁(yè)面修改,工作量評(píng)估一人半天完成
組長(zhǎng)開(kāi)分支:feature/challengeResultUiFix
組員從此分支切出,改完后,推到遠(yuǎn)程分支feature/challengeResultUiFix-review,發(fā)起PR
多人開(kāi)發(fā)
智能輔導(dǎo)開(kāi)發(fā),工作量評(píng)估需要多人N天完成
組長(zhǎng)開(kāi)分支:feature/smartCoach
組員A負(fù)責(zé)答題:feature/smartCoach-answer
組員B負(fù)責(zé)結(jié)果頁(yè)面:feature/smartCoach-result
開(kāi)發(fā)完成后,從當(dāng)前分支feature/smartCoach-answerfeature/smartCoach,發(fā)起PR

commit前綴

feat:功能修改;fix:bug修復(fù)、內(nèi)容+bug地址;style:其余注釋、刪除文件之類的

分支生命流程

  1. develop切出開(kāi)發(fā)若干分支 feature_xxx、feature_xxx等
  2. 要發(fā)版本,從develop分支切出release_版本號(hào)(記得更新app版本號(hào)) ,依次合并各個(gè)feature_xxx
  3. 根據(jù)測(cè)試提出問(wèn)題修改bug,提交到feature_xxx,再向release_發(fā)起pr。
  4. 上線后 發(fā)起release到master的的pr,并基于master打出tag
  5. master依次向develop、各個(gè)開(kāi)發(fā)主干分支發(fā)起pr,同步代碼

release本身不接收任何代碼commit,會(huì)導(dǎo)致增加剝離feature的難度。
有線上bug,從develop切出hotfix代碼,改完推向develop。并發(fā)pr到release_

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 多種多樣的工作流使得在項(xiàng)目中實(shí)施Git時(shí)變得難以選擇。這份教程提供了一個(gè)出發(fā)點(diǎn),調(diào)查企業(yè)團(tuán)隊(duì)最常見(jiàn)的Git工作流。...
    JSErik閱讀 4,614評(píng)論 2 8
  • 那年九月(2011 入學(xué)) 陽(yáng)光融化稚嫩臉龐 汗水浸透衣衫軍裝 一二口號(hào)一致并肩向前 五四青年四海兼程為伴 日子啊...
    念姊新閱讀 277評(píng)論 0 0
  • 一個(gè)人的戰(zhàn)爭(zhēng) 在黎明前開(kāi)始 準(zhǔn)備已久的心情卻潰不成軍 記憶的碎片遺落在欲望的荒原 ——無(wú)處安放 記不清這是第幾次失...
    許二可閱讀 404評(píng)論 1 7

友情鏈接更多精彩內(nèi)容