<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          鵝廠是如何使用 Git 的?

          共 5118字,需瀏覽 11分鐘

           ·

          2020-07-28 12:24

          點擊上方“碼農(nóng)突圍”,馬上關(guān)注

          這里是碼農(nóng)充電第一站,回復(fù)“666”,獲取一份專屬大禮包
          真愛,請設(shè)置“星標(biāo)”或點個“在看”
          來源:騰訊技術(shù)工程
          今天跟大家分享一點鵝廠程序員的 Git 使用經(jīng)驗。
          介紹四種工作流來更好地理解 Git 的項目使用流程,利用其強(qiáng)大的分支功能為自己的項目構(gòu)筑適配的工作流。

          1. 前言

          開發(fā)人員在日常開發(fā)過程中,不可避免地會使用到代碼的版本控制工具,如 svn、git 等等,記得在剛剛?cè)肼毜臅r候,部門使用的主要的 VCS 工具還是 svn,期間有著非常痛苦的 download 經(jīng)歷,下載一份倉庫花了我 2-3 個小時,相比于 svn,git 有著非常多的優(yōu)勢,比如倉庫 clone 速度非??臁⒑诵牡姆种Чδ艿鹊?,后續(xù)公司也在推使用 git 來維護(hù)代碼倉庫,完全摒棄笨重的 svn。
          那么,切換到 git 來維護(hù)代碼倉庫,會對我們的日常開發(fā)造成影響嗎?答應(yīng)是顯然的,首先我們需要學(xué)習(xí) git 的基本概念與用法,然后就需要我們在具體的項目實踐過程中打磨我們的 git 使用技巧,比如靈活的分支、子模塊使用等等,關(guān)于 git 概念或技術(shù)上的介紹,本文不予展開,如果對 git 實現(xiàn)上的細(xì)節(jié)感興趣的話,可以自行搜索學(xué)習(xí)。
          接下來主要跟大家探討的主題是 git 工作流,git 初學(xué)者可能對這個概念并不是很清晰,腦海中想到的可能是 git 的工作原理之類的,其實并不是的,git 工作流指的是多人協(xié)作過程中的 git 的使用流程,不涉及技術(shù)細(xì)節(jié),是一種項目管理、開發(fā)約定的方式。有些同學(xué)可能覺得習(xí)得了 git 三板斧(clone、add commit、push)就算是完成了對 git 的開發(fā)認(rèn)知,其實咱們可能還停留在最原始的想象之中。

          2. 集中式工作流

          集中式工作流,這種工作方式對于使用過 svn 的同學(xué)想必會非常的熟悉,讓我們思考下在 svn 下的協(xié)作體驗,不同的開發(fā)同學(xué)需要依次將本地的修改提交到服務(wù)器,如果有沖突就先解決本地的沖突再提交,這個過程中遠(yuǎn)端的服務(wù)器就像是一個集中管理者,管理著所有人的代碼提交,所以 svn 的開發(fā)協(xié)作流程就是典型的集中式工作流,那切換到 git 場景下,集中式工作流的工作方式又是什么樣的呢?
          首先我們看下 git 的基礎(chǔ)操作框架,如圖 2.1 所示:
          這里有一份中央倉庫,是存放項目代碼的地方,三個開發(fā)人員 A、B、C 分別在本地持有一份中央倉庫的拷貝 - 本地倉庫,這里相比于 svn 的框架只是多了一個本地倉庫;
          接下來我們再來看在項目開發(fā)進(jìn)行了一段時間之后的提交日志是什么樣的,如圖 2.2 所示:
          這里是一條最簡單的 master 分支上的提交日志記錄,那相比于 svn 的框架有啥區(qū)別呢,只要把 master 分支字樣改成 trunk 就變成了一條 svn 的提交記錄。
          最后,我們考慮以下幾個條件:
          1、有無本地倉庫2、默認(rèn)分支是 master 還是 trunk3、提交操作使用 git command 還是 svn command(細(xì)節(jié)忽略)
          我們可以看出 svn 下的集中式工作流同樣適用于 git,只要大家把 svn 相關(guān)的概念全部切換到 git 下即可:1、認(rèn)識本地倉庫2、認(rèn)識默認(rèn)分支 master3、使用 git 的提交命令
          以上三點中的前兩點對于集中式工作流下的開發(fā)者其實是透明的,開發(fā)者只需要將提交命令改成 git 就可以無縫銜接 svn 下的集中式工作流!
          所以,svn 切換到 git 的成本其實還是很低的,只需要你掌握 git 的基礎(chǔ)提交命令!
          git 下的集中式工作流,是一種只使用 master 主分支的開發(fā)方式,這種方式簡單明了,但是缺點是不同開發(fā)人員的提交日志混雜在一起,難以定位問題。

          3. 功能分支工作流

          功能分支工作流,這種工作方式是以集中式工作流為基礎(chǔ),再為不同功能開發(fā)分配單獨的功能分支來進(jìn)行的;這種工作流的主干分支仍然是 master 分支,但是開發(fā)者在進(jìn)行日常需求開發(fā)時不能將代碼直接提交到 master 分支上,一般是為特定的需求新建一個功能分支,并且取一個具有描述性的名字,例如:feat-personal-page、issue-#1702,描述性的名稱可以讓其他開發(fā)者快速地明白這個功能分支的主要作用,提高不同開發(fā)者之間的協(xié)同效率;功能分支功能流的提交日志記錄如圖 3.1 所示:
          從圖中可以看出,相比于集中式工作流,分支歷史看起來更加簡潔、合理,讓不同功能的開發(fā)進(jìn)行隔離,避免不同功能代碼之間產(chǎn)生不利的影響。
          此外,在功能分支上的需求開發(fā)完成之后,我們需要將分支合并到主干分支 master 上,這時候需要進(jìn)行的操作是 pull request,為什么要進(jìn)行 PR 操作,而不是直接進(jìn)行代碼的 merge 呢,這里首先需要大家認(rèn)識 PR 是什么操作,其次需要大家了解 PR 操作的意義;
          功能需求開發(fā)完成之后,需要將本地功能分支推送到中央倉庫的功能分支上,然后在中央倉庫的功能分支上發(fā)起一個 pull request 請求去將功能分支上的修改合并到 master 分支上,這個過程一般是在 GIT 的項目主頁上進(jìn)行,公司內(nèi)部就工蜂的項目主頁,如圖 3.2 所示,是 flutter 項目的某一次 PR 詳情:
          PR 操作給項目帶來的益處有兩點:1、code review2、討論代碼的公共平臺
          前者是每次 PR 操作發(fā)生時會通知相關(guān)者來檢查待合并的代碼,在檢查過程中即完成了對代碼的檢視,這個過程保障了 master 分支上的已合并代碼的健壯性;后者則是因為每次 PR 都會有一個 PR 詳情主頁,如圖 3.2,每一個開發(fā)者都可以針對代碼的實現(xiàn)提出自己的意見,使得討論代碼變成更加便捷高效,且為代碼變更回顧提供了可能。
          功能分支工作流是 git 項目開發(fā)非常靈活使用的一種方式,但是對于大型的項目而言,需要為不同的分支分配更加具體的角色。

          4.Gitflow 工作流

          Gitflow 工作流是目前非常成熟的一個方案,它定義了一個圍繞項目發(fā)布的嚴(yán)格分支模型,通過為代碼研發(fā)、項目發(fā)布以及維護(hù)分配獨立的分支來讓項目的迭代過程更加地順暢,不同于之前的集中式工作流以及功能分支工作流,gitflow 工作流常駐的分支有兩個:主干分支 master、開發(fā)分支 dev,此外針對項目研發(fā)的各個階段,設(shè)定了特定的分支。
          階段分支常駐 master、dev 研發(fā) feature 熱修復(fù) hotfix 發(fā)布 release
          首先針對常駐分支,如圖 4.1
          常駐分支表示在項目提交歷史中一直存在的分支,這里 master 分支主要跟蹤項目正式發(fā)布的代碼歷史,dev 分支主要跟蹤項目代碼研發(fā)的提交歷史;此外在 master 分支上通常會為某次版本發(fā)布分配一個標(biāo)簽來記錄版本號,這為以后項目排查定位提供便利。
          接下來,我們來看 gitflow 工作流中,代碼研發(fā)階段的工作流程。
          如圖 4.2 所示,開發(fā)階段開啟某一個需求時需要從 dev 分支上新建功能分支 feature,圖中所示為兩個 feature 分支,代表同時有兩個功能在開發(fā)中,這里的 feature 分支使用跟功能分支工作流中的使用方式是一樣的,在需求開發(fā)完成之后需要提交 PR 請求合并進(jìn) dev 分支,完成之后即可刪除對應(yīng)的功能分支。
          很多時候,在需求研發(fā)過程中,線上的代碼可能會出現(xiàn)問題,這時候需要我們進(jìn)行及時的修復(fù),這就是項目迭代過程中的熱修復(fù)階段。
          如圖 4.3 所示,假設(shè)我們在開發(fā)的過程中線上出現(xiàn)了一個 bug,這時候我們需要從 master 的標(biāo)簽 v0.1 上檢出一份分支代碼 hotfix,修復(fù)并驗證好了之后,需要將 hotfix 代碼分別合并到 master /dev 分支上,并在 master 的提交上打上一個標(biāo)簽 v0.2,這里需要將熱修復(fù)的代碼分別合并進(jìn)兩個常駐分支是因為需要保障兩邊代碼的一致性。
          最后,我們來看下項目迭代的發(fā)布階段,我們需要將之前功能開發(fā)完成的特性發(fā)布到線上去,如圖 4.4 所示
          首先在 dev 分支的提交處新建 release 分支,在這個分支上進(jìn)行 bug 修復(fù)、面向發(fā)布的一些任務(wù),這個分支不做任何功能上的任務(wù),完成之后將 release 分支再分別合并進(jìn) master/dev 分支,并在 master 提交上打上標(biāo)簽 v1.0,這樣一個發(fā)布階段的代碼操作就完成了
          最后我們來看發(fā)布之后的目前的日志記錄情況,如圖 4.5 所示,這里可以將沒有用的分支 hotfix、release、feature 均刪除了,可以看出我們的常駐分支就 master/dev,最下面的 feature 表示仍在開發(fā)中。
          gitflow 工作流是目前比較很成熟的方案,它的優(yōu)點有:
          1、發(fā)布迭代流程更順暢2、使得代碼有了更加嚴(yán)謹(jǐn)?shù)捻椖拷Y(jié)構(gòu),方便定位排查問題
          大型的項目 / 迭代速度快的推薦使用這種工作流程!

          5.Forking 工作流

          最后介紹一種開源項目常用的工作流 ——Forking 工作流,介紹之前首先需要了解什么是 fork 操作,如圖 5.1 所示
          fork 操作是在個人遠(yuǎn)程倉庫新建一份目標(biāo)遠(yuǎn)程倉庫的拷貝,操作很簡單,比如 github 上在項目的主頁點擊 fork 按鈕即可。
          明白了 fork 操作之后,我們來看下 forking 工作流的流程,如圖 5.2 所示:
          首先開發(fā)者 A 擁有一個遠(yuǎn)端倉庫,這時候有一個開發(fā)者 C 也想?yún)⑴c A 的這個項目的開發(fā)工作,那他就可以 fork 一份 A 的這個倉庫,之后在 c 的個人倉庫里就有了這份代碼庫,后續(xù)開發(fā)者 C 就可以在自己的這個項目里進(jìn)行開發(fā)工作,c 在完成了某個功能的實現(xiàn)之后,可以給 A 的倉庫發(fā)一個 PR 請求,這時候會通知到開發(fā)者 A 有新的 PR,A 如果有問題可以直接在這個 PR 里提,開發(fā)者 C 可以進(jìn)行進(jìn)一步的修改,最后 A 通過了 C 的這份 PR 請求,就會將 C 的代碼合并進(jìn) A 的倉庫,這樣就完成了 A / 代碼庫新特性的開發(fā)。同時如果有其他開發(fā)者對 A 的項目有興趣也會進(jìn)行相同的操作。
          這里注意到 開發(fā)者 B/C 并不是 A 代碼庫的開發(fā)人員,而是第三方開發(fā)者,所以這種工作流主要用于開源項目!

          6. 總結(jié)

          最后回顧下這幾種 git 工作流,集中式工作流可以說是 git 工作流的基礎(chǔ),初學(xué)者可以無縫地從 svn 的模式切換到 git 的模式;功能分支工作流在集中式的基礎(chǔ)上又引入了功能分支,靈活地利用了 git 的分支特性,功能分離 / PR 優(yōu)化了日常工作的效率;gitflow 工作流則是為大型項目的迭代過程服務(wù)的,指定了一個嚴(yán)格的分支模型,使得迭代流程更加順暢;forking 工作流則是開源項目的首選,想要為開源項目做貢獻(xiàn)就必須要懂得這種工作流!
          當(dāng)然,以上描述的這些工作流并不是實際工作中 git 使用的準(zhǔn)則,這只是一些推薦的使用方式,在具體的項目研發(fā)過程中,我們需要結(jié)合項目以及團(tuán)隊現(xiàn)狀作出取舍,總結(jié)出適合自己團(tuán)隊的工作流,才能讓 git 更好地為我們服務(wù)!

          ---END---
          重磅!碼農(nóng)突圍-技術(shù)交流群已成立

          掃碼可添加碼農(nóng)突圍助手,可申請加入碼農(nóng)突圍大群和細(xì)分方向群,細(xì)分方向已涵蓋:Java、Python、機(jī)器學(xué)習(xí)、大數(shù)據(jù)、人工智能等群。
          一定要備注:開發(fā)方向+地點+學(xué)校/公司+昵稱(如Java開發(fā)+上海+拼夕夕+猴子),根據(jù)格式備注,可更快被通過且邀請進(jìn)群

          ▲長按加群

          推薦閱讀

          ? GitHub宣布已將所有代碼永久封存于北極地底1000年!網(wǎng)友炸鍋了:我寫的bug終于能流傳永世了!
          ?? 優(yōu)秀!94年出生的她,受聘為深圳大學(xué)正教授!
          ???使用 IDEA 幾分鐘就重構(gòu)了同事800 行"又臭又長" 的類!真香!
          ???雷軍1994年寫的老代碼曝光,被稱像詩一樣優(yōu)雅
          ?? 推薦 33 個 IDEA 最牛配置,好用到飛起來!
          ?? 同事:你居然還在用 try catch 處理異常?有點Low啊
          最近面試BAT,整理一份面試資料Java面試BAT通關(guān)手冊,覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
          獲取方式:點“在看”,關(guān)注公眾號并回復(fù)?BAT?領(lǐng)取,更多內(nèi)容陸續(xù)奉上。
          如有收獲,點個在看,誠摯感謝明天見(??ω??)??

          瀏覽 36
          點贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  国产a片偷拍网站视频 | 影音先锋无码专区 | 一黄大毛片 | 亲子伦视频一区二区三区 | 黄片在线网站 |