团队Git Flow指南

• Git Flow指南

常规：

1. 团队项目以git flow模型管理分支，使用bitbucket托管，以pull request方式做code review。

 

个人开发流程：

1）在bitbucket团队项目页面上fork这个库（以后简称repo）

2）克隆fork到你名下的库，注意是你名下的

git clone git@bitbucket.org:yourname/repo.git

3）git flow初始化及track远程develop分支

cd repo
git flow init -d
git pull origin develop
git branch --set-­ups­tream develop origin­/de­velop

4）按git flow的规范（见分支规范）操作，比如开一个新特性分支

git flow feature start feature-xxx

git add .
git commit -m 'xxxx' 

git flow feature finish feature-xxx

5）推送最新的代码到远程develop分支

git push origin develop

6）当完成一次task或是bugfixed的编码后，发起PR（pull request），一般是从你的develop分支到团队项目的develop分支。

7）为了保持与团队项目代码库的更新，做如下操作

git remote add upstream git@bitbucket.org:fstone/xxx.git
git fetch upstream
git merge upstream/develop develop

PR规范

1. title简短清晰，附上basecamp todo id或者bitbucket issue id（如果是bugfix）
2. 更多内容补充在description里
3. 全员review

 

分支规范：

1. master分支上的代码总是稳定的（stable build），随时可以发布出去。
2. develop上的代码总是从feature上合并过来的，可以进行Nightly Builds，但不直接在develop上进行开发。当develop上的feature足够多以至于可以进行新版本的发布时，可以创建release分支。
3. release分支基于develop，进行很简单的修改后就被合并到master，并打上tag，表示可以发布了。紧接着release将被合并到develop；此时develop可能往前跑了一段，出现合并冲突，需要手工解决冲突后再次合并。这步完成后就删除release分支。
4. 当从已发布版本中发现bug要修复时，就应用到hotfix分支了。hotfix基于master分支，完成bug修复或紧急修改后，要merge回master，打上一个新的tag，并merge回develop，删除hotfix分支。

命名规范:

1. 特性分支以Basecamp里的 project-id.todos-id命名（通过URL查看），例如feature-xxxx.xxxxxx

其他：

1. 不是紧急的bug，在下一个release版本之前修复，commit描述为 bugfixed-issue id.
2. 紧急的bug，开hotfix分支修复，以Basecamp里的 project-id.todos-id命名（通过URL查看）。