常规:
- 团队项目以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-upstream develop origin/develop
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)为了保持与团队项目代码库的更新,做如下操作
7)为了保持与团队项目代码库的更新,做如下操作
git remote add upstream git@bitbucket.org:fstone/xxx.git
git fetch upstream
git merge upstream/develop develop
PR规范
- title简短清晰,附上basecamp todo id或者bitbucket issue id(如果是bugfix)
- 更多内容补充在description里
- 全员review
分支规范:
- 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分支。
命名规范:
- 特性分支以Basecamp里的 project-id.todos-id命名(通过URL查看),例如feature-xxxx.xxxxxx
其他:
- 不是紧急的bug,在下一个release版本之前修复,commit描述为 bugfixed-issue id.
- 紧急的bug,开hotfix分支修复,以Basecamp里的 project-id.todos-id命名(通过URL查看)。