git-flow

1. 开发新功能

(1) 准备开发

首先要为新开发的feature取一个名字，使用命令：

   git flow feature start <name>

此时本地会基于develop分支（develop分支可以认为是开发主干，下面会简称主干），创建并切换到一个新的分支feature/。

(2) 本地开发和提交

专心研发指定的功能，不要做其它事情，包括（非该feature引入的）bug fix。 有点像使用SVN时“将代码Hold在本地不提交”的状态。 但git有本地代码库，可以做提交、回退，甚至再开分支。

常用git命令：

   git add <file>：添加新文件（或老文件的修改）到暂存区   git add -u：添加所有老文件的修改到暂存区   git commit：将暂存区内容做本地提交   git status：查看状态

可以本地编版本，单独提测feature。 当然，非该feature引入的BUG，要推迟到release分支打出来之后再修改。

(3) 多人协作

同一个feature的开发需要多人协作时，首先把分支推到服务器上：

     git push origin feature/<name>

其他人从服务器上把分支取下来：

     git fetch     git checkout feature/<name>

获取最新更新（类似SVN Update）：

     git pull origin feature/<name> --rebase     # 如果出现冲突，需要手工解决并提交

将本地已提交的修改推送到服务器（类似SVN Commit）：

     git push origin feature/<name>

(4) 完成开发

先确认feature分支上所有修改都已经本地提交过了。 如果有多人协作，还要确认大家都已经推到服务器，并且已经从获取了服务器的最新更新。 如果feature单独提测，要等到基本无BUG后再做此操作。

执行命令：

     git flow feature finish <name>

这条命令会将feature分支上所有修改合并成一个，提交到主干。 如果没有产生冲突，则会要求填写提交日志，这个日志会在主干上永久保存，要认真写。 如果产生冲突，本地解决并提交后，重新执行上面的finish命令。 成功后，feature分支会被删除，本地位于主干。

之后更新并推送主干（即develop分支）：

     git pull origin develop --rebase     git push origin develop

2. 发布主干版本

(1) 准备发布

先把准备发布的feature都finish掉，保证本地主干是最新的。 然后确定发布版本号，它会作为版本发布时的TAG名称。执行命令：

     git flow release start <version>

此时本地会基于主干，创建并切换到一个新的分支release/。

多人协作方式详见上面的 1 (3)，只是 feature/ 换成 release/。

release分支上主要是bug fix，小的需求变更等，不要做大feature。 另外release分支上的每一个提交，日后都会在主干上永久保留，所以日志一定要认真写。

(2) 完成发布

当release分支测试完成后，就可以发布版本了。 确认release分支上所有修改都已经本地提交过了。 且大家都已经推到服务器，并且已经从获取了服务器的最新更新。

使用命令：

    git flow release finish <version>

这条命令会在release分支当前位置打TAG，并把release分支合并到主干。 如果产生冲突，本地解决并提交后，重新执行上面的finish命令。 成功后，feature分支会被删除，本地位于主干。

之后更新并推送主干（即develop分支），详见 1（4）。

另外完成发布还会把本地master分支更新到指向最新版本，也要推送到服务器：

    git push origin master

3. 发布紧急修复版本

与发布主干版本类似，参见上面的2。两点不同：

(1) 开始发布时要指定基准版本号。基于做紧急修复的命令如下：

    git flow release start <version> <base>

(2) 如果不是最新发布版（即与master不重合），结束发布时不会更新master。