2017-08-29

Git Workflows

概要

随着团队不断的壮大，业务流程迭代。代码工作流的规范是显而易见的。为了保证开发速度，我们不断改进完善这个发布流程，让这个过程更简单、高效。
这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的Pull Request功能，体系地讲解了各种工作流的应用。
在阅读过程中，请记住这些工作流是指导原则，而不是具体规则。我们想向您展示什么是可能的，因此您可以混合和匹配来自不同工作流的方面，以满足您的个人需求。

常见问题：

我们以使用SVN的工作流来使用Git有什么不妥？
如何控制开发版本？
Git方便的branch在哪里，团队多人如何协作？冲突了怎么办？如何进行发布控制？
经典的master-发布、develop-主开发、hotfix-bug修复如何避免代码不经过验证上线？
如何在GitHub上面与他人一起协作，star-fork-pull request是怎样的流程？

集中式工作流

集中式工作流以中央仓库作为项目所有修改的单点实体。相比 SVN 缺省的开发分支 trunk ，Git 叫做master，所有修改提交到这个分支上。本工作流只用到 master 这一个分支。

工作方式

要发布修改到正式项目中，开发者要把本地 master 分支的修改『推』到中央仓库中。这相当于 svn commit 操作，但 push 操作会把所有还不在中央仓库的本地提交都推上去。

push

Gitflow工作流

Gitflow工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

特点

健壮的用于管理大型项目的框架
分支分配明确
功能分支，在做准备、维护和记录发布也使用各自的分支

工作方式

Gitflow工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到要中央仓库中。

分支命名：master版本、develop开发、release-*发布、feature-*功能、hotfix-*修复

特点

├── master
	├── hotfix-*
	├── release-*
	├── develop
		├── hotfix-*
		├── release-*
		├── feature-*

维护分支

master版本分支

正式发布历史分支：用于管理发布的版本，发布Tag

develop开发分支

功能的集成分支：用于开发项目

feature功能分支

功能分支：每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。
新功能提交应该从不直接与master分支交互，

案例

小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于master分支，而是应该基于develop分支进行开发

创建feature分支

<!-- develop分支 -->
$ git checkout develop
<!-- 创建dev分支并切换 -->
$ git checkout -b feature-dev
Switched to branch 'feature-dev'
=>
<!-- 以develop创建dev分支并切换 -->
git checkout -b feature-dev develop

编辑、暂存、提交

$ git status
$ git add
$ git commit -m "branch"
[feature-dev fec145a] branch
 1 file changed, 1 insertion(+)
$ git push

完成合并

<!-- 拉取develop代码并合并 -->
$ git pull origin develop
$ git checkout develop
<!-- 合并指定分支到feature-dev分支 -->
$ git merge feature-dev
$ git push
<!-- 删除分支 -->
$ git branch -d feature-dev

release发布分支

发布分支：用于发布准备的专门分支。
一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上 —— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。
一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。另外，这些从新建发布分支以来的做的修改要合并回develop分支。