項目開發中git經常使用命令、git工做流、git分支模型

#新建代碼庫
git init # 在當前目錄新建一個Git代碼庫
git init [project-name] # 新建一個目錄，將其初始化爲Git代碼庫
git clone [url] # 下載一個項目和它的整個代碼歷史
#配置git
git config [--global] user.name "your name"
git config [--global] user.email "your email address"
#分支
git branch -r # 查看遠程分支
git br -v # 查看各個分支最後提交信息
git checkout [branch-name] # 切換到指定分支，並更新工做區
#標籤
git tag # 列出全部tag
git show [tag] # 查看tag信息
#遠程同步
git remote -v # 顯示全部遠程倉庫
git remote show [remote] # 顯示某個遠程倉庫的信息
git fetch [remote] # 下載遠程倉庫的全部變更
git pull [remote] [branch] # 取回遠程倉庫的變化，並與本地分支合併

git開發模型
feature br - develop br - release br - hotfix br - master - tag

exampleproj
|-- exampleproj-master-tag-0.1
|-- exampleproj-develop
|-- exampleproj-feature
|-- exampleproj-develop
|-- exampleproj-release
|-- exampleproj-hotfix
|-- exampleproj-master-tag-0.2
...

git經典協同模型：
中心倉庫：包含master和develop兩個分支
分支分類：

• 主要分支：master和develop分支
• 支持性分支：特性分支，發佈分支，熱補丁分支

簡單介紹一下的各類分支：

• Master - 與產品環境代碼保持一致的分支，也就是每次發佈完成以後發佈的功能分支就要合併於此，以保持Master更新。
• Develop - 開發的主分支，Feature和Release分支會基於此分支。
• Feature - 具體要開發的功能的分支，完成後合併到Develop。
• Release - 用於發佈新版本的分支，完成後合併到Develop和Master。
• HotFix - 用於緊急修復已發佈的產品問題的分支，完成後合併到Develop和Master。

　　最右邊的是主分支，黃色的是develop分支，好比開發版本1.0，開發過程當中master出現問題要修改，產生的就是紅色點的，叫熱補丁分支。
　　紅色的熱補丁分支修改完成後，除了要合併到master外，還要合併到正在開發的develop分支，這樣以後更新的版本如2.0合併到master後纔不會出現一樣的bug。完成後熱補丁分支也就完成使命，能夠銷燬了。
　　綠色部分的爲發佈分支。即當版本1.0（黃色部分）開發完成後，黃色部分可能繼續開發下去，好比接着開發2.0，而後將1.0的版本以發佈分支獨立處出來，進行測試階段的運行，而後途中出現問題，修復而且合併到develop分支，當該版本再也不出現問題後沒，便可將該分支合併到master，同時也要何合併到正在開發的develop分支（由於若是發佈分支有修復了bug的話，合併後才能使下一個版本不會出現一樣的bug），完成後，發佈分支使命也完成了。
　　最左邊的紫紅色部分，爲特性分支，即當你在開發產品時，突發奇想一想到了新功能或者新的解決方法或者其它等新嘗試，但不敢保證能夠完成這部分的開發，因此以特性分支獨立出來開發。若是開發可以完成，既能夠合併到develop分支裏。

 

Git Flow中的分支

主分支

主分支是全部開發活動的核心分支。全部的開發活動產生的輸出物最終都會反映到主分支的代碼中。主分支分爲master分支和development分支。

 

master分支

master分支上存放的應該是隨時可供在生產環境中部署的代碼（Production Ready state）。當開發活動告一段落，產生了一份新的可供部署的代碼時，master分支上的代碼會被更新。同時，每一次更新，最好添加對應的版本號標籤（TAG）。

 

develop分支

develop分支是保存當前最新開發成果的分支。一般這個分支上的代碼也是可進行每日夜間發佈的代碼（Nightly build）。所以這個分支有時也能夠被稱做「integration branch」。

當develop分支上的代碼已實現了軟件需求說明書中全部的功能，經過了全部的測試後，而且代碼已經足夠穩定時，就能夠將全部的開發成果合併回master分支了。對於master分支上的新提交的代碼建議都打上一個新的版本號標籤（TAG），供後續代碼跟蹤使用。

所以，每次將develop分支上的代碼合併回master分支時，咱們均可以認爲一個新的可供在生產環境中部署的版本就產生了。一般而言，「僅在發佈新的可供部署的代碼時才更新master分支上的代碼」是推薦全部人都遵照的行爲準則。基於此，理論上說，每當有代碼提交到master分支時，咱們可使用Git Hook觸發軟件自動測試以及生產環境代碼的自動更新工做。這些自動化操做將有利於減小新代碼發佈以後的一些事務性工做。

 

輔助分支

輔助分支是用於組織解決特定問題的各類軟件開發活動的分支。輔助分支主要用於組織軟件新功能的並行開發、簡化新功能開發代碼的跟蹤、輔助完成版本發佈工做以及對生產代碼的缺陷進行緊急修復工做。這些分支與主分支不一樣，一般只會在有限的時間範圍內存在。

輔助分支包括：

• 用於開發新功能時所使用的feature分支；
• 用於輔助版本發佈的release分支；
• 用於修正生產代碼中的缺陷的hotfix分支。

以上這些分支都有固定的使用目的和分支操做限制。從單純技術的角度說，這些分支與Git其餘分支並無什麼區別，但經過命名，咱們定義了使用這些分支的方法。

feature分支

使用規範：

• 能夠從develop分支發起feature分支
• 代碼必須合併回develop分支
• feature分支的命名可使用除master，develop，release-*，hotfix-*以外的任何名稱

feature分支（有時也能夠被叫作「topic分支」）一般是在開發一項新的軟件功能的時候使用，這個分支上的代碼變動最終合併回develop分支或者乾脆被拋棄掉（例如實驗性且效果很差的代碼變動）。

通常而言，feature分支代碼能夠保存在開發者本身的代碼庫中而不強制提交到主代碼庫裏。

 

release分支

使用規範：

• 能夠從develop分支派生
• 必須合併回develop分支和master分支
• 分支命名慣例：release-*

release分支是爲發佈新的產品版本而設計的。在這個分支上的代碼容許作小的缺陷修正、準備發佈版本所需的各項說明信息（版本號、發佈時間、編譯時間等等）。經過在release分支上進行這些工做可讓develop分支空閒出來以接受新的feature分支上的代碼提交，進入新的軟件開發迭代週期。

當develop分支上的代碼已經包含了全部即將發佈的版本中所計劃包含的軟件功能，而且已經過全部測試時，咱們就能夠考慮準備建立release分支了。而全部在當前即將發佈的版本以外的業務需求必定要確保不能混到release分支以內（避免由此引入一些不可控的系統缺陷）。

成功的派生了release分支，並被賦予版本號以後，develop分支就能夠爲「下一個版本」服務了。所謂的「下一個版本」是在當前即將發佈的版本以後發佈的版本。版本號的命名能夠依據項目定義的版本號命名規則進行。

hotfix分支

使用規範：

• 能夠從master分支派生
• 必須合併回master分支和develop分支
• 分支命名慣例：hotfix-*

除了是計劃外建立的之外，hotfix分支與release分支十分類似：均可以產生一個新的可供在生產環境部署的軟件版本。

當生產環境中的軟件遇到了異常狀況或者發現了嚴重到必須當即修復的軟件缺陷的時候，就須要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復工做。

這樣作的顯而易見的好處是不會打斷正在進行的develop分支的開發工做，可以讓團隊中負責新功能開發的人與負責代碼緊急修復的人並行的開展工做。

 

經常使用分支命名示例：
tag/1.0.1 標籤
master 主要
develop/1.0.2 開發
feature/my-xxx-feature 新功能 （建立自develop分支，開發完成後先合併到develop，而後刪除分支）
release/1.1 預發佈 （建立自develop分支，肯定沒問題合併到master和develop，而後刪除分支）
fixbug-name 修復bug （建立自master分支，開發完成後合併到master和develop，而後刪除分支）
hotfix-name 補丁 （建立自master分支，肯定合併到master和develop，而後刪除分支）

參考文章：

http://blog.csdn.net/dengsilinming/article/details/8000622 [Git 經常使用命令大全]
http://www.cnblogs.com/cspku/articles/Git_cmds.html [Git經常使用命令]
http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html [經常使用 Git 命令清單]
http://blog.csdn.net/zymx14/article/details/53415231?locationNum=11&fps=1 [git原理圖及git協同模型]
http://www.oschina.net/translate/a-successful-git-branching-model [介紹一個成功的 Git 分支模型]
http://blog.csdn.net/gong0791/article/details/47148989 [經常使用 Git 開發模型]
http://www.cnblogs.com/itech/p/5188929.html [四種常見 Git 工做流比較]
http://www.jianshu.com/p/ca5ee4ea6420 [Git 工做流的一些經驗分享]
http://blog.jobbole.com/76867/ [Git工做流指南：Gitflow工做流]
https://www.ibm.com/developerworks/cn/java/j-lo-git-mange/index.html [Git 分支管理最佳實踐]
http://semver.org/lang/zh-CN/ [語義化版本 2.0.0]
http://cheenwe.cn/2016-08-02/git-branch-and-usage/ [Git分支命名規範]
http://blog.sina.com.cn/s/blog_70c0040c0102vlkt.html [Git分支管理策略]
http://www.yiibai.com/git/git_handling_conflicts.html [Git處理衝突]
http://www.cnblogs.com/best/p/7474442.html [一個小時學會Git]

 

版權聲明：本文采用署名-非商業性使用-相同方式共享(CC BY-NC-SA 3.0 CN)國際許可協議進行許可,轉載請註明做者及出處。 本文標題：php高效遍歷文件夾、高效讀取文件 本文連接：http://www.cnblogs.com/sochishun/p/7384188.html 本文做者：SoChishun (郵箱:14507247#qq.com | 博客:http://www.cnblogs.com/sochishun/)發表日期：2017年8月17日