为什么从这里开始
也许你对 git 的命令已经很熟悉，能够熟练的新建一个仓库，拉取、恢复、Merge你的项目，但每次用的时候依旧会有疑惑 ~ “这玩意儿到底哪里好用了？”。我相信这种经历不止我一个人体会过，记了一大堆命令 ~ “到底要怎么用？”“上一次到哪了？我干了什么？”。前几天看了一篇介绍git-workflow的文章，突然觉得自己对git有了新的认识 ~ “原来这些，早就有人想过了!”。人们之所以爱用git，并不是因为他那一大堆繁琐的命令，而是把这些命令按照一定的规则组织起来所形成的工作流 - Workflows
不同类型的工作流
自从2005年第一版发布以后，在这十几年中，出现了各种不同的工作流，不能说哪一种最好，但你总能发现一个最适合自己项目的。下面是几种比较有代表性的工作流，你可以在自己的项目中直接使用，或者在这些工作流上稍作修改找到最适合自己的。
集中式工作流（Centralized Workflow）
这种工作流只有一个公共的仓库，每个成员工作时，从公共的仓库克隆项目到本地仓库；在本地完成修改之后，提交到本地；fetch远程仓库（可能此时仓库有其他人更新过），rebase你的修改到更新过的仓库；将本地分支推送的公共仓库。
Git-flow Workflow
这个工作流有5种类型的分支
- 主分支
- master
- develop
- 协助分支
- feature
- release
- hotfix
这种工作流的仓库中总会存在着两个主分支 master以及develop，master分支中保存的是已经或者将要发布的版本，他可能不是最新的，但一定是最稳定的；develop分支就如其名字所示，开发工作主要集中在这个分支上。当开发一个新功能是，你需要从develop新建一个分支（feature什么的），完成工作后再merge回develop分支。
feature分支从develop分支中衍生出来，主要是进行一些新特性的开发
release分支是测试分支，当你develop中的所有新功能都完成之后，在合并到master分支发布之前，需要新建一个release分支进行测试，当测试没有问题时，将其合并到master分支发布
hotfix分支直接从master分支衍生，主要是用来做一些紧急情况的修复，修复完成之后合并回master分支
Fork Workflow
这种工作流在一些开源项目中比较常用，github也采用的是这种工作流。
对于一个开源项目，一般会有一个主仓库，只有项目的管理者可以直接与这个仓库进行提交，其它开发者需要从主仓库fork出来一个新的仓库，所有的工作都在fork出来的仓库中操作，完成后如果想merge到主仓库，需要向项目管理员申请。
总结
git的这些工作流，没有好坏之分，关键是找到适合自己的，并且在自己的项目中去遵守与实践。
一些在工作流中用到的命令
# 新建一个空的仓库
git init --bare 项目名称.git
# 添加远程仓库
git remote add 简称 ssh://software@172.16.0.30/~/yafeng/.git
# 向远程仓库推送
git push 简称 master(分支名称)
# 创建并切换到分支
git checkout -b develp
# 查看当前分支
git branch
# 克隆远程仓库分支
git clone -b <指定分支名> <远程仓库地址>
