Git作为目前强有力的软件团队合作工具，除去git工具的基础使用，怎样在项目团队中合理地使用强大的分布式版本控制软件，以实现敏捷高效的开发工作，也是学习Git的重要内容。本文主要参考atlassian，在该文章的基础上，做了一些标注与说明，并结合git常用操作，对Git工作流作一些介绍与分析。

---

关于Git基本操作，推荐廖雪峰的教程，戳Git基础教程

---

分布式工作流

在集中式版本控制系统如SVN、CVN下工作时，有一台中央服务器保存了项目的全部核心代码库，客户端全部是其的离线拷贝，所有提交最终都要汇总到中心服务器，并且可以影响全部离线拷贝。

集中式工作流

和集中式版本控制系统相比，分布式版本控制系统Git的安全性要高很多，因为每个人电脑里都有完整的版本库，这样，工作的时候就不需要联网了，因为版本都是在自己的电脑上。
使用Git为开发工作流提供了一些好处：

• 它给每个开发者自己的整个项目的本地副本。 这个隔离的环境使每个开发人员独立于项目的所有其他更改工作，他们可以添加提交到本地存储库，完全忘记上游开发，直到它们方便。
• 它让你访问Git的鲁棒分支和合并模型。 与SVN不同，Git分支被设计为一种故障安全机制，用于集成代码和在存储库之间共享更改。

分支管理

Git工作流使用最好遵循标准的使用规范，下面列出常用的分支：

1. Master分支
   这个分支也称为Production分支，包含了最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
2. Develop 分支
   这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
3. Feature 分支
   这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
4. Release分支
   当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支。

• 这个分支只应该做Bug修复、文档生成和其它面向发布任务。一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。
• 另外，这些从新建发布分支以来的做的修改要合并回develop分支。

5. Hotfix分支
   当我们在Production发现新的Bug时候，我们需要创建一个Hotfix分支。这是唯一可以直接从master分支fork出来的分支。修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

Git工作流

工作实践

在服务器上建立好远程中央仓库。

创建Develop分支

第一步为Mater分支建立一个Develop分支。一个简单的方法是一个开发人员在本地创建一个空的Develop分支并将其推送到服务器：
git branch develop git push -u origin develop

项目组其他开发人员克隆中央仓库克隆，并切换至Develop分支：
git clone ssh://user@host/path/to/repo.git git checkout -b develop origin/develop

开发者A与B并行开发功能

开发者A与B开始各自的功能开发，工作应在新分支上展开，新的Feature分支应基于
Develop分支建立。
git checkout -b feature-X develop

在各自功能分支上进行编辑、暂存、提交：
git status git add git commit

开发者A完成并提交新功能

开发者A在完成功能后首先从从远程获取Develop分支最新版本并merge到本地。
git pull origin develop
将Feature分支合并至本地Develop分支。
git checkout develop git merge feature-A

合并成功后推送至远程仓库。
git push origin develop
推送时可能遇到冲突解决，则先git pull抓取最新提交再在本地解决冲突后再push。

开发者A进行版本发布

开发者A完成功能准备进行版本发布时，基于Develop分支创建Release分支，这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，像是一个专门用于改善发布的功能分支。
git checkout -b release-0.1 develop
当准备好发布时，开发者A将首先发布分支合并回master分支，并push到服务器仓库。
git checkout master git merge release-0.1 git push
只要有合并到master分支，就应该打好Tag
以方便跟踪。
git tag -a 0.1 -m "Initial public release" master git push --tags
在发布分支中已经提交的更新需要在后面的新功能中也要是可用的，所以应合并至Develop分支。之后删除发布分支。
git checkout develop git merge release-0.1 git push git branch -d release-0.1

Bug反馈与修复

当发布后收到Bug反馈后，开发者从master
分支上拉出了一个维护分支Hotfix，提交修改以解决问题，然后直接合并回master分支：

git checkout -b hotfix master
/*Fix the bug*/
git checkout master
git merge hotfix
git push

与发布分支一样，维护分支中新加这些重要修改需要包含到develop分支中。

git checkout develop
git merge hotfix
git push
git branch -d hotfix