日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

Brach

云知道

團(tuán)隊(duì)項(xiàng)目的Git分支如何管理？

Brach


Git 是目前最流行的源代碼管理工具 。大量的軟件項(xiàng)目由 GitHub、Bitbucket 和 GitLab 這樣的云服務(wù)平臺或是私有的 Git 倉庫來管理 。在使用 Git 時(shí)通常會遇到的一個(gè)問題是采用何種分支管理實(shí)踐 ， 即如何管理倉庫中作用不同的各類分支 。和軟件開發(fā)中的其他實(shí)踐一樣 ， Git 分支管理并沒有普遍適用的最佳做法 ， 而只有對每個(gè)團(tuán)隊(duì)和項(xiàng)目而言最適合的做法 。
簡單來說 ， 在項(xiàng)目開發(fā)中使用多個(gè)分支會帶來額外的管理和維護(hù)開銷 ， 但是多個(gè)分支對于項(xiàng)目的團(tuán)隊(duì)合作、新功能開發(fā)和發(fā)布管理都是有一定好處的 。不同的團(tuán)隊(duì)可以根據(jù)團(tuán)隊(duì)人員組成和意愿、項(xiàng)目的發(fā)布周期等因素選擇最適合的策略 ， 找到最適合團(tuán)隊(duì)的管理方式 。這里講一下三種常見的 Git 分支管理方式 。單主干單主干的分支實(shí)踐（Trunk-based development ， TBD）在 SVN 中比較流行 。
【Brach】Google 和 Facebook 都使用這種方式 。trunk 是 SVN 中主干分支的名稱 ， 對應(yīng)到 Git 中則是 master 分支 。TBD 的特點(diǎn)是所有團(tuán)隊(duì)成員都在單個(gè)主干分支上進(jìn)行開發(fā) 。當(dāng)需要發(fā)布時(shí) ， 先考慮使用標(biāo)簽（tag） ， 即 tag 某個(gè) commit 來作為發(fā)布的版本 。如果僅靠 tag 不能滿足要求 ， 則從主干分支創(chuàng)建發(fā)布分支 。
bug 修復(fù)在主干分支中進(jìn)行 ， 再 cherry-pick 到發(fā)布分支 。圖 1 是 TBD 中分支流程的示意圖 。圖 1. TBD 中的分支流程的示意圖由于所有開發(fā)人員都在同一個(gè)分支上工作 ， 團(tuán)隊(duì)需要合理的分工和充分的溝通來保證不同開發(fā)人員的代碼盡可能少的發(fā)生沖突 。持續(xù)集成和自動化測試是必要的 ， 用來及時(shí)發(fā)現(xiàn)主干分支中的 bug 。
因?yàn)橹鞲煞种撬虚_發(fā)人員公用的 ， 一個(gè)開發(fā)人員引入的 bug 可能對其他很多人造成影響 。不過好處是由于分支所帶來的額外開銷非常小 。開發(fā)人員不需要頻繁在不同的分支之間切換 。GitHub flowGitHub flow 是 GitHub 所使用的一種簡單的流程 。該流程只使用兩類分支 ， 并依托于 GitHub 的 pull request 功能 。
在 GitHub flow 中 ， master 分支中包含穩(wěn)定的代碼 。該分支已經(jīng)或即將被部署到生產(chǎn)環(huán)境 。master 分支的作用是提供一個(gè)穩(wěn)定可靠的代碼基礎(chǔ) 。任何開發(fā)人員都不允許把未測試或未審查的代碼直接提交到 master 分支 。對代碼的任何修改 ， 包括 bug 修復(fù)、hotfix、新功能開發(fā)等都在單獨(dú)的分支中進(jìn)行 。
不管是一行代碼的小改動 ， 還是需要幾個(gè)星期開發(fā)的新功能 ， 都采用同樣的方式來管理 。當(dāng)需要進(jìn)行修改時(shí) ， 從 master 分支創(chuàng)建一個(gè)新的分支 。新分支的名稱應(yīng)該簡單清晰地描述該分支的作用 。所有相關(guān)的代碼修改都在新分支中進(jìn)行 。開發(fā)人員可以自由地提交代碼和 push 到遠(yuǎn)程倉庫 。當(dāng)新分支中的代碼全部完成之后 ， 通過 GitHub 提交一個(gè)新的 pull request 。
團(tuán)隊(duì)中的其他人員會對代碼進(jìn)行審查 ， 提出相關(guān)的修改意見 。由持續(xù)集成服務(wù)器（如 Jenkins）對新分支進(jìn)行自動化測試 。當(dāng)代碼通過自動化測試和代碼審查之后 ， 該分支的代碼被合并到 master 分支 。再從 master 分支部署到生產(chǎn)環(huán)境 。圖 2 是 GitHub flow 分支流程的示意圖 。圖 2. Github flow 中的分支流程的示意圖GitHub flow 的好處在于非常簡單實(shí)用 。
開發(fā)人員需要注意的事項(xiàng)非常少 ， 很容易形成習(xí)慣 。當(dāng)需要進(jìn)行任何修改時(shí) ， 總是從 master 分支創(chuàng)建新分支 。完成之后通過 pull request 和相關(guān)的代碼審查來合并回 master 分支 。GitHub flow 要求項(xiàng)目有完善的自動化測試、持續(xù)集成和部署等相關(guān)的基礎(chǔ)設(shè)施 。每個(gè)新分支都需要測試和部署 ， 如果這些不能自動化進(jìn)行 ， 會增加開發(fā)人員的工作量 ， 導(dǎo)致無法有效地實(shí)施該流程 。

推薦閱讀