常规：
- 团队项目以git flow模型管理分支，使用bitbucket托管，以pull request方式做code review。
个人开发流程：
- 在bitbucket页面上操作fork project repo
- git clone git@bitbucket.org:<project>
cd <project>
git flow init -d
git pull origin develop
git branch --set-upstream develop origin/develop
git flow feature start feature1
修改README
git add .
git commit -m ‘修改README‘
git flow feature finish feature1
git push origin develop
- 发起PR 开发者本地的develop 到office的develop分支
- 项目经理合并到office的develop分支，这样office中的develop分支就是最新的了
- 服务器发布 git pull 即可
另外一个developer或者项目经理（repo持有人）修改了代码
- local repo拉取 upstream的最新内容，合并到你本地的分支之后，你本地的内容就跟upstream一样，而你fork下来的远程repo反而内容不如你本地的新
- git remote add upstream ‘url’
- git pull upstream develop
分支规范：
- master分支上的代码总是稳定的（stable build），随时可以发布出去。
- develop上的代码总是从feature上合并过来的，可以进行Nightly Builds，但不直接在develop上进行开发。当develop上的feature足够多以至于可以进行新版本的发布时，可以创建release分支。
- release分支基于develop，进行很简单的修改后就被合并到master，并打上tag，表示可以发布了。紧接着release将被合并到develop；此时develop可能往前跑了一段，出现合并冲突，需要手工解决冲突后再次合并。这步完成后就删除release分支。
- 当从已发布版本中发现bug要修复时，就应用到hotfix分支了。hotfix基于master分支，完成bug修复或紧急修改后，要merge回master，打上一个新的tag，并merge回develop，删除hotfix分支。
命名规范:
- 完成功能/特性开发只有，release分支的Tag，以Basecamp里的 project-id.todos-id命名（通过URL查看）。
其他：
- 不是紧急的bug，在下一个release版本之前修复，commit描述为 bugfixed-issue id.
- 紧急的bug，开hotfix分支修复，以Basecamp里的 project-id.todos-id命名（通过URL查看）。
