3 4 Git分支 分支開發工作流

2021-10-02 05:09:22 字數 2071 閱讀 1149

現在你已經學會新建和合併分支,那麼你可以或者應該用它來做些什麼呢? 在本節,我們會介紹一些常見的利用分支進行開發的工作流程。而正是由於分支管理的便捷,才衍生出這些典型的工作模式,你可以根據專案實際情況選擇一種用用看。

因為 git 使用簡單的三方合併,所以就算在一段較長的時間內,反覆把乙個分支合併入另乙個分支,也不是什麼難事。 也就是說,在整個專案開發周期的不同階段,你可以同時擁有多個開放的分支;你可以定期地把某些特性分支合併入其他分支中。

事實上我們剛才討論的,是隨著你的提交而不斷右移的指標。 穩定分支的指標總是在提交歷史中落後一大截,而前沿分支的指標往往比較靠前。

通常把他們想象成流水線(work silos)可能更好理解一點,那些經過測試考驗的提交會被遴選到更加穩定的流水線上去。

你可以用這種方法維護不同層次的穩定性。 一些大型專案還有乙個proposed(建議) 或pu: proposed updates(建議更新)分支,它可能因包含一些不成熟的內容而不能進入next或者master分支。 這麼做的目的是使你的分支具有不同級別的穩定性;當它們具有一定程度的穩定性後,再把它們合併入具有更高階別穩定性的分支中。 再次強調一下,使用多個長期分支的方法並非必要,但是這麼做通常很有幫助,尤其是當你在乙個非常龐大或者複雜的專案中工作時。

特性分支對任何規模的專案都適用。 特性分支是一種短期分支,它被用來實現單一特性或其相關工作。 也許你從來沒有在其他的版本控制系統(vcs)上這麼做過,因為在那些版本控制系統中建立和合併分支通常很費勁。 然而,在 git 中一天之內多次建立、使用、合併、刪除分支都很常見。

你已經在上一節中你建立的iss53hotfix特性分支中看到過這種用法。 你在上一節用到的特性分支(iss53hotfix分支)中提交了一些更新,並且在它們合併入主幹分支之後,你又刪除了它們。 這項技術能使你快速並且完整地進行上下文切換(context-switch)——因為你的工作被分散到不同的流水線中,在不同的流水線中每個分支都僅與其目標特性相關,因此,在做**審查之類的工作的時候就能更加容易地看出你做了哪些改動。 你可以把做出的改動在特性分支中保留幾分鐘、幾天甚至幾個月,等它們成熟之後再合併,而不用在乎它們建立的順序或工作進度。

考慮這樣乙個例子,你在master分支上工作到c1,這時為了解決乙個問題而新建iss91分支,在iss91分支上工作到c4,然而對於那個問題你又有了新的想法,於是你再新建乙個iss91v2分支試圖用另一種方法解決那個問題,接著你回到master分支工作了一會兒,你又冒出了乙個不太確定的想法,你便在c10的時候新建乙個dumbidea分支,並在上面做些實驗。 你的提交歷史看起來像下面這個樣子:

現在,我們假設兩件事情:你決定使用第二個方案來解決那個問題,即使用在iss91v2分支中方案;另外,你將dumbidea分支拿給你的同事看過之後,結果發現這是個驚人之舉。 這時你可以拋棄iss91分支(即丟棄c5c6提交),然後把另外兩個分支合併入主幹分支。 最終你的提交歷史看起來像下面這個樣子:

請牢記,當你做這麼多操作的時候,這些分支全部都存於本地。 當你新建和合併分支的時候,所有這一切都只發生在你本地的 git 版本庫中 —— 沒有與伺服器發生互動。

3 4 Git 分支 分支開發工作流

現在你已經學會新建和合併分支,那麼你可以或者應該用它來做些什麼呢?在本節,我們會介紹一些常見的利用分支進行開發的工作流程。而正是由於分支管理的便捷,才衍生出這些典型的工作模式,你可以根據專案實際情況選擇一種用用看。因為 git 使用簡單的三方合併,所以就算在一段較長的時間內,反覆把乙個分支合併入另乙...

Git分支開發模式

這篇部落格將主要介紹團隊中如何使用git分支模式進行開發。先介紹一下分支 分支分為遠端分支和本地分支。建立版本庫時,缺省會有乙個master遠端分支,我們轉殖到本地,於是建立了本地master分支。預設情況下,乙個遠端分支,乙個本地分支,在本地寫 寫完之後更新到遠端分支。我們稱這種模式為單分支模式。...

git 分支開發規範

git 進行 管理和開發時,分支的管理也是非常必要的 1 master分支 部署生產環境的分支,這個分支只能從其他分支合併,如develop release hotfix,不能在這個分支直接修改 2 develop分支 我們的主開發分支,是乙個穩定的版本,通常由release分支合併過來,通常發到s...