git工作流设计

对于源码管理和产品线管理为了避免混乱,应该有个大致的管理方案:
项目名假如为:tj_dj
则产品管理线:(主机)
主分支–master
开发分支–develop-tj_dj
发布分支–release-tj_dj
特性分支(短生命线分支)–f-[特性名]-tj_dj
修复分支–hotfix-tj_dj

轻量级开发情况:(AB机间没有网络)
在各自本机建立环境,本地建立好bare仓库和本地开发仓库。
总体上要求,bare仓库是同名的,但在自己的本地开发仓库中把远程仓库命名个性化。Dell为例:
dell-前缀。
技巧:
bare仓库用来fetch和push的“箱子”,为远程仓库。
使用拷贝方式来和其它机共享bare仓库。
各机器为主工作时,则要使用很多分支技术来merge其它机的进度代码。

多人联合开发情况:
这里就仁者见仁,智者见智了。但是最典型的就是gitflow了。但不是起对了几个分支名就行了。要得其要领。
原则:
master和develop分支是稳定分支,一直存在。
master只允许release和hotfix分支来的merge
develop日常开发
feature上开发功能,功能成熟后合并到develop上
release是从develop上分出来,bug修复后,打上tag后,要同时合并回develop和master
很小的bug修复会则会在hotfix上进行。
1). 首先将远程代码拉取到本地
  git clone xxx
  git checkout -b develop origin/develop
2).新建feature分支
  git checkout -b feature
3).多人在feature上开发,如果中途需要将develop的变更合入feature,所有人需要将本地的代码变更提交到远程
  git fetch origin
  git rebase origin/feature
  git push origin feature
然后由feature负责人rebase develop分支,删除原来feature分支,重新新建feature分支;
  git fetch origin
  git rebase origin/feature
  git rebase develop
  git push origin :feature
  git push origin feature
这样可以保证feature保持线性变更;
4).feature开发完成后,所有人需要将本地的代码变更提交到远程
  git fetch origin
  git rebase origin/feature
  git push origin feature
然后由feature负责人rebase develop分支,然后将feature分支合入develop,删除feature;
  git fetch origin
  git rebase origin/feature
  git rebase develop
  git checkout develop
  git merge feature
  git push origin :feature
这样可以保证develop保持线性变更,各feature的变更完整可追溯;
5).合入feature后拉出对应的release/feature分支,后续bug修复在release/feature上
  git checkout develop
  git checkout -b release/feature
release/feature分支的同步合并与feature分支相同
6).release/feature分支bug修复完成后,拉取对应的tag推送远程进行发布
  git tag -a v1.0 -m ‘feature发布’
  git push origin v1.0
之后将release/feature合入develop分支,然后删除
  git rebase develop
  git checkout develop
  git merge release/feature
  git push origin :release/feature
7).发布完成后将release合入master分支,保证master为最新稳定版本(实际操作为发起merge request)