建议依照这篇文章的方式走
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 好的问题。