Git的優勢不少,可是這裏只列出我認爲很是突出的幾點。css
感興趣的,能夠去看一下Git自己的設計,內在的架構體現了不少的優點,不愧是出資天才程序員Linus (Linux之父) 之手git
雖然有這麼優秀的版本管理工具,可是咱們面對版本管理的時候,依然有很是大得挑戰,咱們都知道你們工做在同一個倉庫上,那麼彼此的代碼協做必然帶來不少問題和挑戰,以下:程序員
大部分開發人員如今使用Git就只是用三個甚至兩個分支,一個是Master, 一個是Develop, 還有一個是基於Develop打得各類分支。這個在小項目規模的時候還勉強能夠支撐,由於不少人作項目就只有一個Release, 可是人員一多,並且項目週期一長就會出現各類問題。github
就像代碼須要代碼規範同樣,代碼管理一樣須要一個清晰的流程和規範sql
Vincent Driessen 同窗爲了解決這個問題提出了 A Successful Git Branching Modelbash
下面是Git Flow的流程圖架構
上面的圖你理解不了? 不要緊,這不是你的錯,我以爲這張圖自己有點問題,這張圖應該左轉90度,你們應該就很用以理解了。分佈式
也就是咱們常用的Master分支,這個分支最近發佈到生產環境的代碼,最近發佈的Release, 這個分支只能從其餘分支合併,不能在這個分支直接修改工具
這個分支是咱們是咱們的主開發分支,包含全部要發佈到下一個Release的代碼,這個主要合併與其餘分支,好比Feature分支post
這個分支主要是用來開發一個新的功能,一旦開發完成,咱們合併回Develop分支進入下一個Release
當你須要一個發佈一個新Release的時候,咱們基於Develop分支建立一個Release分支,完成Release後,咱們合併到Master和Develop分支
當咱們在Production發現新的Bug時候,咱們須要建立一個Hotfix, 完成Hotfix後,咱們合併回Master和Develop分支,因此Hotfix的改動會進入下一個Release
全部在Master分支上的Commit應該Tag
分支名 feature/*
Feature分支作完後,必須合併回Develop分支, 合併完分支後通常會刪點這個Feature分支,可是咱們也能夠保留
分支名 release/*
Release分支基於Develop分支建立,打完Release分以後,咱們能夠在這個Release分支上測試,修改Bug等。同時,其它開發人員能夠基於開發新的Feature (記住:一旦打了Release分支以後不要從Develop分支上合併新的改動到Release分支)
發佈Release分支時,合併Release到Master和Develop, 同時在Master分支上打個Tag記住Release版本號,而後能夠刪除Release分支了。
分支名 hotfix/*
hotfix分支基於Master分支建立,開發完後須要合併回Master和Develop分支,同時在Master上打一個tag
a. 建立develop分支
git branch develop
git push -u origin develop
b. 開始新Feature開發
git checkout -b some-feature develop
# Optionally, push branch to origin: git push -u origin some-feature # 作一些改動 git status git add some-file git commit
c. 完成Feature
git pull origin develop
git checkout develop
git merge --no-ff some-feature git push origin develop git branch -d some-feature # If you pushed branch to origin: git push origin --delete some-feature
d. 開始Relase
git checkout -b release-0.1.0 develop # Optional: Bump version number, commit # Prepare release, commit
e. 完成Release
git checkout master
git merge --no-ff release-0.1.0 git push git checkout develop git merge --no-ff release-0.1.0 git push git branch -d release-0.1.0 # If you pushed branch to origin: git push origin --delete release-0.1.0 git tag -a v0.1.0 master git push --tags
f. 開始Hotfix
git checkout -b hotfix-0.1.1 master
g. 完成Hotfix
git checkout master git merge --no-ff hotfix-0.1.1 git push git checkout develop git merge --no-ff hotfix-0.1.1 git push git branch -d hotfix-0.1.1 git tag -a v0.1.1 master git push --tags
實際上,當你理解了上面的流程後,你徹底不用使用工具,可是實際上咱們大部分人不少命令就是記不住呀,流程就是記不住呀,腫麼辦呢?
總有聰明的人創造好的工具給你們用, 那就是Git flow script.
brew install git-flow
apt-get install git-flow
wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash
初始化: git flow init
開始新Feature: git flow feature start MYFEATURE
Publish一個Feature(也就是push到遠程): git flow feature publish MYFEATURE
獲取Publish的Feature: git flow feature pull origin MYFEATURE
完成一個Feature: git flow feature finish MYFEATURE
開始一個Release: git flow release start RELEASE [BASE]
發佈Release: git flow release finish RELEASE
別忘了git push --tags
開始一個Hotfix: git flow hotfix start VERSION [BASENAME]
發佈一個Hotfix: git flow hotfix finish VERSION
上面講了這麼多,我知道還有人記不住,那麼又有人作出了GUI 工具,你只須要點擊下一步就行,工具幫你幹這些事!!!
當你用Git-flow初始化後,基本上你只須要點擊git flow菜單選擇start feature, release或者hotfix, 作完後再次選擇git flow菜單,點擊Done Action. 我勒個去,我實在想不到還有比這更簡單的了。
目前SourceTree支持Mac, Windows, Linux.
這麼好的工具請問多少錢呢? 免費!!!!
廣大VS的福音
GitFlow for Visual Studio