git工作流程-java開發(fā)java經(jīng)驗技巧

《git工作流程-java開發(fā)java經(jīng)驗技巧》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在工程資料-天天文庫。

1、Git工作流程-編程開發(fā)技術(shù)Git工作流程原文出處：阮一峰Git作為一個源碼管理系統(tǒng)，不口J避免涉及到多人協(xié)作。協(xié)作必須有一個規(guī)范的工作流程，讓大家有效地合作，使得項口井井有條地發(fā)展下去?！惫ぷ髁鞒獭痹谟⒄Z里，叫做”workflow"或者”flow",原意是水流，比喻項目像水流那樣，順暢、口然地向前流動，不會發(fā)生沖擊、對撞、甚至漩渦。本文介紹三種廣泛使用的工作流程:?Gitflow?Githubflow?Gitlabflow如果你對Git還不是很熟悉，可以先閱讀卜?面的文章。?《Git使用規(guī)范流程》?《常用Git命令清單》?《Gi

2、t遠(yuǎn)程操作詳解》一、功能驅(qū)動本文的三種工作流程，有一個共同點：都采用”功能驅(qū)動式開發(fā)”(Feature-drivendevelopment,簡稱FDD)。它指的是，需求是開發(fā)的起點，先有需求再有功能分支(featurebranch)或者補丁分支(hotfixbranch)□完成開發(fā)后，該分支就合并到主分支，然后被刪除。二、Gitflow最早誕生、并得到廣泛采用的一種工作流程，就是Gitflow。2.1特點它最主要的特點有兩個。首先，項目存在兩個長期分支。?主分支master?開發(fā)分支develop前者用于存放對外發(fā)布的版木，任何時

3、候在這個分支拿到的，都是穩(wěn)定的分布版;后者用于日常開發(fā)，存放最新的開發(fā)版。其次，項目存在三種短期分支。?功能分支(featurebranch)?補丁分支(hotfixbranch)?預(yù)發(fā)分支(releasebranch)一旦完成開發(fā)，它們就會被合并進develop或master,然后被刪除。Gitflow的詳細(xì)介紹，請閱讀我翻譯的中文版《Git分支管理策略》。2.2評價Gitflow的優(yōu)點是清晰可控，缺點是相對復(fù)雜，需要同時維護兩個長期分支。大多數(shù)工具都將master當(dāng)作默認(rèn)分支，可是開發(fā)是在develop分支進行的，這導(dǎo)致經(jīng)常要

4、切換分支，非常煩人。更大問題在于，這個模式是基于”版木發(fā)布”的，目標(biāo)是一段吋間以后產(chǎn)出一個新版本。但是，很多網(wǎng)站項目是”持續(xù)發(fā)布”，代碼一有變動，就部署一次。這時，master分支和develop分支的差別不大，沒必要維護兩個長期分支。三、Githubf1owGithubflow是Gitflow的簡化版，專門配合”持續(xù)發(fā)布”。它是Github.com使用的工作流程。3.1流程它只有一個長期分支，就是master,因此用起來非常簡單。官方推薦的流程如下。?第一步：根據(jù)需求，從master拉出新分支，不區(qū)分功能分支或補丁分支。?第二步

5、：新分支開發(fā)完成后，或者需要討論的時候，就向master發(fā)起一個pullrequest（簡稱PR）。?第三步：PullRequest既是一個通知，讓別人注意到你的請求，又是一種對話機制，大家一起評審和討論你的代碼。對話過程中，你還可以不斷提交代碼。?第四步：你的PullRequest被接受，合并進master,重新部署后，原來你拉出來的那個分支就被刪除。（先部署再合并也可。）2.2評價Githubflow的最大優(yōu)點就是簡單，對于”持續(xù)發(fā)布”的產(chǎn)品，可以說是最合適的流程。問題在于它的假設(shè)：master分支的更新與產(chǎn)品的發(fā)布是一致的。

6、也就是說，master分支的最新代碼，默認(rèn)就是當(dāng)前的線上代碼?？墒?，有些吋候并非如此，代碼合并進入master分支，并不代表它就能立刻發(fā)布。比如，蘋果商店的APP提交審核以后，等一段吋間才能上架。這吋，如果還有新的代碼提交，master分支就會與剛發(fā)布的版本不一致。另一個例了是，有些公司冇發(fā)布窗口，只冇指定時間才能發(fā)布，這也會導(dǎo)致線上版本落后Fmaster分支。上面這種情況，只有master—個主分支就不夠用了。通常，你不得不在master分支以外，另外新建一個production分支跟蹤線上版本。四、Gitlabf1owGitl

7、abflow是Gitflow與Githubflow的綜合。它吸取了兩者的優(yōu)點，既有適應(yīng)不同開發(fā)環(huán)境的彈性，又有單一主分支的簡單和便利。它是Gitlab.com推薦的做法。3.1上游優(yōu)先Gitlabflow的最大原則叫做”上游優(yōu)先”（upsteamfirst）,即只存在一個主分支master,它是所有其他分支的”上游”。只有上游分支采納的代碼變化,才能應(yīng)用到其他分支。Chromium項口就是一?個例子，它明確規(guī)定，上游分支依次為：?LinusTorvalds的分支?了系統(tǒng)（比如netdev）的分支?設(shè)備廠商（比如三星）的分支2.2持

8、續(xù)發(fā)布Gitlabflow分成兩種情況，適應(yīng)不同的開發(fā)流程。對于”持續(xù)發(fā)布”的項目，它建議在master分支以外，再建立不同的環(huán)境分支。比如，”開發(fā)環(huán)境”的分支是master,”預(yù)發(fā)環(huán)境”的分支是pre-production,”生產(chǎn)環(huán)境”的分支是p