1. 程式人生 > >介紹一個成功的 Git 分支模型 Release 分支

介紹一個成功的 Git 分支模型 Release 分支

轉載自:http://www.cnblogs.com/yaks/p/5666400.html

英文原文:

http://nvie.com/posts/a-successful-git-branching-model/

中文版:

在這篇文章中,我提出一個開發模型。我已經將這個開發模型引入到我所有的專案裡(論在工作還是私人)已經一年有餘,並且它被證明是非常成功的。我打算寫這些已經很久了,但我一直找不到時間來做,現在終於有時間了。我不會講任何專案的具體細節,僅是關於分支策略和釋放管理相關內容。

介紹一個成功的 Git 分支模型

它主要體現了Git對我們原始碼版本的管理。

為何是Git?

對於Git與其他

集中式程式碼管理工具相比的優缺點的全面討論,請參見這裡。這樣的爭論總是喋喋不休。作為一個開發者,與現今的其他開發工具相比較,我更喜歡Git。Git真得改變了開發者對於合併和分支的思考。我曾經使用經典的CVS/Subversion,然而每次的合併/分支和其他行為總讓人擔驚受怕(“小心合併裡的衝突,簡直要命!”)。

但是對於Git來說,這些行為非常簡單和搞笑,它們被認為是日常工作中的核心部分。例如,在很多CVS/Subversion書裡,分支與合併總是在後面的章節中被討論(對於高階使用者使用),然而在每個Git書中,在第3章就已經完全涵蓋了(作為基礎)。

簡單和重複的特性帶來的結果是:分支與合併不再是什麼可以害怕的

東西。分支/合併被認為對於版本管理工具比其他功能更重要。

關於工具,不再多說,讓我們直接看開發模型吧。這個模型並不是如下模型:在管理軟體開發進度方面,面對每個開發過程,每個隊員必須按一定次序開發。

分散式而非集中式

對於這種分支模型,我們設定了一個版本庫,它運轉良好,這是一個事實上 版本庫。不過請注意,這個版本庫只是被認為是中心版本庫(因為Git是一個分散式版本管理系統,從技術上來講,並沒有一箇中心版本庫)。我們將把這個版本庫稱為原始庫,這個名字對所有的Git使用者來說都很容易理解。

介紹一個成功的 Git 分支模型

每個開發者都對origin庫拉程式碼和提交程式碼。但是除了集中式的存取程式碼關係,每個開發者也可以從子團隊的

其他隊友那裡獲得程式碼版本變更。例如,對於2個或多個開發者一起完成的大版本變更,為了防止過早地向origin庫提交工作內容,這種機制就變得非常有用。在上述途中,有如下子團隊:Alice和Bob,Alice和David,Clair和David。

從技術上將,這意味著,Alice建立了一個Git的遠端節點,而對於Bob,該節點指向了Bob的版本庫,反之亦然。

主分支

介紹一個成功的 Git 分支模型

在核心部分,研發模型很大程度上靠其他現有模型支撐的。中心庫有2個可一直延續的分支:

  • master分支
  • develop分支

每個Git使用者都要熟悉原始的master分支。與master分支並行的另一個分支,我們稱之為develop分支。

我們把原始庫/master庫認作為主分支,HEAD的原始碼存在於此版本中,並且隨時都是一個預備生產狀態。

輔助性分支

我們的開發模型使用了各種輔助性分支,這些分支與關鍵分支(master和develop)一起,用來支援團隊成員們並行開發,使得易於追蹤功能,協助生產釋出環境準備,以及快速修復實時線上問題。與關鍵分支不同,這些分支總是有一個有限的生命期,因為他們最終會被移除。

我們用到的分支型別包括:

  • 功能分支
  • 釋出分支
  • 熱修復分支

每一種分支有一個特定目的,並且受限於嚴格到規則,比如:可以用哪些分支作為源分支,哪些分支能作為合併目標。我們馬上將進行演練。

從技術角度來看,這些分支絕不是特殊分支。分支的型別基於我們使用的方法來進行分類。它們理所當然是普通的Git分支。

功能分支

介紹一個成功的 Git 分支模型

可能是develop分支的分支版本,最終必須合併到develop分支中。

分支命名規則:除了master、develop、release-*、orhotfix-*之外,其他命名均可。

功能分支(有時被稱為topic分支)通常為即將釋出或者未來發布版開發新的功能。當新功能開始研發,包含該功能的釋出版本在這個還是法確定釋出時間的。功能版本的實質是隻要這個功能處於開發狀態它就會存在,但是最終會或合併到develop分支(確定將新功能新增到不久的釋出版中)或取消(譬如一次令人失望的測試)。

功能分支通常存在於開發者的軟體庫,而不是在原始碼庫中。

建立一個功能分支

開始一項功能的開發工作時,基於develop建立分支。

1 2 $ git checkout -b myfeature develop Switched to a new branch"myfeature"

合併一個功能到develop分支

完成的功能可以合併進develop分支,以明確加入到未來的釋出:

1 2 3 4 5 6 7 8 $ git checkout develop Switched to branch develop $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Dele<a href="http://www.wuseyun.com/htmldata/tag/46/TED.html">TED</a> branch myfeature (was 05e9557). $ git push origin develop

no-ff標誌導致合併操作建立一個新commit物件,即使該合併操作可以fast-forward。這避免了丟失這個功能分支存在的歷史資訊,將該功能的所有提交組合在一起。 比較:

介紹一個成功的 Git 分支模型

後一種情況,不可能從Git歷史中看到哪些提交一起實現了一個功能——你必須手工閱讀全部的日誌資訊。如果對整個功能進行回退 (比如一組提交),後一種方式會是一種真正頭痛的問題,而使用no-ffflag的情況則很容易.

是的,它會建立一個新的(空)提交物件,但是收益遠大於開銷。

不幸的是,我還沒找到一種方法,讓no-ff時作為合併操作的預設選項,但它應該是可行的。

Release 分支

Release分支可能從develop分支分離而來,但是一定要合併到develop和master分支上,它的習慣命名方式為:release-*。

Release分支是為新產品的釋出做準備的。它允許我們在最後時刻做一些細小的修改。他們允許小bugs的修改和準備釋出元資料(版本號,開發時間等等)。當在Release分支完成這些所有工作以後,對於下一次打的釋出,develop分支接收features會更加明確。

從develop分支建立新的Release分支的關鍵時刻是develop分支達到了釋出的理想狀態。至少所有這次要釋出的features必須在這個點及時合併到develop分支。對於所有未來準備釋出的features必須等到Release分支建立以後再合併。

在Release分支建立的時候要為即將發行版本分配一個版本號,一點都不早。直到那時,develop分支反映的變化都是為了下一個發行版,但是在Release分支建立之前,下一個發行版到底叫0.3還是1.0是不明確的。這個決定是在Release分支建立時根據專案在版本號上的規則制定的。

建立一個release分支

Release分支是從develop分支建立的。例如,當前產品的發行版本號為1.1.5,同事我們有一個大的版本即將發行。develop 分支已經為下次發行做好了準備,我們得決定下一個版本是1.2(而不是1.1.6或者2.0)。所以我們將Release分支分離出來,給一個能夠反映新版本號的分支名。

1 2 3 4 5 6 7 $ git checkout -b release-1.2 develop Switched to a new branch"release-1.2" $ ./bump-version.sh 1.2 Files modified suc<a href="http://www.wuseyun.com/htmldata/tag/11/CES.html">CES</a>sfully, version bumped to 1.2. $ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2

相關推薦

介紹一個成功Git 分支模型 Release 分支

轉載自:http://www.cnblogs.com/yaks/p/5666400.html 英文原文: http://nvie.com/posts/a-successful-git-branching-model/ 中文版: 在這篇文章中,我

介紹一個成功Git 分支模型(A successful Git branching model)

開始一項功能的開發工作時,基於develop建立分支。 ? 1 2 $ git checkout -b myfeature develop Switched to a new branch "myfeature"

一個成功Git 分支模型

規則 人的 做的 現在 ges 每一個 管理工具 nta nac 在這篇文章中介紹的開發模型在大約一年前已經在我的私有項目和工作引入的,而且已經被證明是非常成功的。我想寫一些關於這個模型的東西已經好一段時間了,但是一直苦於沒有時間,不過現在可以了。我不想探討任何項目細節,只

一個成功Git 分支模型(適用於商業應用開發)

還原 如果 功能 角度 想要 允許 chang lai ive 在這篇文章中,我將推廣一下大約一年前我介紹過的一些項目(公私皆有)中使用的開發模型,它們的結果都非常成功。有段時間我非常想寫出來分享一下,但是我至今才抽出時間來。我不會言及任何項目細節,僅討論分支策略和發布管

一個diaodiao的Git分支模型(譯)

原文出自:http://nvie.com/posts/a-successful-git-branching-model/ 以下是翻譯內容: 在這篇文章裡,將展示我在大約一年前為我的一些專案(包括工作上的和私人的)所提出的開發模型,它最終也被證明是非常成功的。我早就打算寫這樣一篇文章,但

Git分支模型(master/hotfix/develop/feature/release)

1.分支管理 1.1 總覽(一張流程圖給大家先鎮鎮驚) 它主要體現了Git對我們原始碼版本的管理。 (轉載者加)一般情況: ● master和develop並行。 ● master上始終是最穩定的程式碼,develop是正在開發的程式碼。 ● feature則是某個開發為了

Git 分支模型與開發規範

work 所有 upload git 分支 -a 最新 push wechat let 01、分支模型 master:長期分支,一般用於管理對外發布版本,每個 commit 對一個 tag,也就是一個發布版本 develop:長期分支,一般用於作為日常開發匯總,

git 一個分支程式碼提交到遠端倉新分支(新建分支

背景: 從branchA分支拉了一份程式碼,做了一些修改,但是不想提交到branchA分支,想新建一個分支branchB儲存程式碼。 操作方法: 新增本地需要提交程式碼 git add . 1 提交原生代碼 git commit -m "add my code to new branchB" 1

git---怎樣將分支上的一個單檔案合併到主分支上(master)

一、首先切換到主分支  注意將分支上的資料全部提交 以免造成資料衝突或丟失 git checkeout master   二、選擇要合併的檔案  git checkout --patch 分支名稱  要合併的檔案路徑   三、此時檔案將合併完成

正確的 Git 提交記錄和分支模型

兩年前編寫的文章 Git Style,是參考業界實踐對 Git 提交記錄格式和分支模型所做的總結。本文在 Git Style 基礎上,再次描述提交記錄的格式和分支模型,並介紹兩個工具 commitizen 和 gitflow,分別處理維護提交記錄格式和分支切換的工作。 C

成熟的 Git 分支模型

個人部落格原文: 成熟的 Git 分支模型 今天介紹一下工作中會用到的 Git 分支模型。 先貼上圖以表敬意 閒言 在學校不管是自己寫課程設計還是給老師做專案,有 2 到 3 個人一起協作開發時就會使用 Git ,但是隻是簡單用了它所提供的程式碼協作功能,

Git 分支模型

翻譯自:https://nvie.com/posts/a-successful-git-branching-model/ 在這篇文章中,主要介紹 Git 分支模型。不會談論任何專案的細節,只討論分支策略和釋出管理。 Git分散式和集中式理解 我們配置了中央儲存庫可以很完美的配合該分支模型工作。這裡需

Git-程式碼分支模型&遠端庫操作

程式碼版本控制是我最近要細化學習的東西,以下是這一天的日報 Git分支是程式碼版本控制的核心,我所熟悉的開發模型就是: 建立一個新的分支 從預設分支master分下來一個分支,雖然你也可以從任何現有分支下拉下一個分支,但是 有個不成文的規定,就是一般master

經典的Git進行原始碼管理的分支模型

本文介紹一種使用Git進行原始碼管理的分支模型,著重於如何使用Git更好的管理我們的原始碼。 我假定您對Git有一定了解,會使用基本的Git命令進行一些簡單的原始碼管理工作。這不是一篇Git使用教程。 文章的主要思想源自以下連結: 根據自己的使用情況進行了補充。

Git如何強制拉取一個遠程分支到本地分支(轉載)

get cal question 識別 this control 指令 轉載 ould 有時候,我們在使用git pull指令想把一個遠程分支拉取到本地分支的時候,老是會拉取失敗,這一般是因為某種原因,本地分支和遠程分支的內容差異無法被git成功識別出來,所以git pul

我與Git的那些破事(下)--分支模型

在上篇文章中,我提到了Git的基本概念和一些本人實際專案中的總結。然而,最近讀了Vincent Driessen寫的一篇文章,覺得他總結的太好了,站在他肩膀上忍不住將自己的理解分享出來。Vincent Driessen的文章連線放在本文最下方,有需要的童鞋可去參考一二。 話不多上,乾貨頂上。 分支模型 上述

git clone 某個分支或者所有分支

tps 分支 git clone http dev bsp branch ade .net clone 某個分支: git clone -b dev5 https://git.coding.net/aiyongbao/tradepc.git trade

Git手冊 - 本地多分支操作

git分支管理一)新建/刪除分支#git branch //查看當前項目所有的分支,並以*顯示當前工作分支#git branch branchName //新建一個分支#git checkout branchName //切換到另外的分支#git checkout -

git 查看遠程分支、本地分支、創建分支、把分支推到遠程repository、刪除本地分支

cli one cmd util ace http span toc tor git 查看遠程分支、本地分支、創建分支、把分支推到遠程repository、刪除本地分支 [plain] view plain copy $ git branch -

git 獲取遠程分支的代碼

解決辦法 lan 解釋 分支 net mas nbsp eas csdn Git clone只能clone遠程庫的master分支,無法clone所有分支,解決辦法如下: 1. 找一個幹凈目錄,假設是git_work2. cd git_work3. git clone ht