建議依照這篇文章的方式走
http://ihower.tw/blog/archives/5140
主要分支
master: 永遠處在 production-ready 狀態
develop: 最新的下次發佈開發狀態 支援性分支
Feature branches: 開發新功能都從 develop 分支出來，完成後 merge 回 develop
Release branches: 準備要 release 的版本，只修 bugs。從 develop 分支出來，完成
後 merge 回 master 和 develop
Hotfix branches: 等不及 release 版本就必須馬上修 master 趕上線的情況。
會從 master 分支出來，完成後 merge 回 master 和 develop
我公司原本都是用ＳＶＮ來做多人開發跟維護
大概去年的５月份搭配gitlab(公司內部架一台vm server)逐步替換成git
git 真的蠻好用的,但是merge的方向要對,剛開始的時候會弄錯方向
所以我後來直接印一張貼在我的螢幕旁邊（笑
http://ppt.cc/LVpi
※ 引述《readonly (唯讀)》之銘言：
: ※ 引述《strlen (strlen)》之銘言：
: : 上個月剛換工作
: : 目前工作內容主要是以開發與維護公司自有網站為主
: : 網站是很常見的的LAMP架構
: : 但因為公司一直以來都沒有使用版本控制
: : 所以整個測試機上的程式真的就像垃圾場一樣...
: : 現在主管說要導入版本控制系統
: : 要我選一個弄
: : 我之前只有用過svn
: : 現在想玩玩看git
: : 這一兩天看了些教學文後大致上基本的操作與觀念都OK
: : 現在的問題是多人開發的流程該怎麼樣規範會比較好?
: : 目前公司實際在寫程式的有六個人
: : 未來可能還會繼續增加
: : 但公司裡的人幾乎都沒有碰過git
: : 之前的作業方式都是直接使用連線網路磁碟到測試機上改
: : 然後直接看結果
: : 本機當然大家都是使用Windows，測試機是CentOS
: : 我現階段想到的規範是
: : 1.將某一台測試機當作git server
: : 大家把程式clone回自己的本機開發
: : 改好了再push回測試機
: : 2.開發還是在原本的測試機上作
: : 只是不同人就開不同的branch
: : 做好了在合併就好?
: : 或是有其它更好的方式呢?
: : 因為自己對git也不是很熟
: : 不太確定哪一種作法會比較好
: : 想請問大家在目前使用git的多人作業流程大概是怎麼樣呢?
: 如果你真的要問的話，這兩個都不對。個人覺得你們的流程要整個改過。
: 首先要有個維護 tree 的人，負責 merge，還有 tree 上面的 code
: 是正確能跑的。
: git branch 是為了新功能開的，例如新功能可能要好幾個 patch/commit，
: 在一個 branch 做好之後一次送出去 （svn 是一個 commit 馬上就送上去
: 被別人看見）。
: 你們不是選 svn 好還是 git 好的問題。