Git 工作流管理

Git 使用规范

研发阶段

共享版本库在 http://git.businessmatics.io/gogs，我们通过 GitLab（开源）搭建了 git 版本库管理平台；

在每个项目中，会有一个常设的 master 分支，该分支作为每个项目的开发主干，一般来说，主干上的代码都应该保持干净，可用，尽量跟线上版本一致；

上图显示了在我们选用的 git flow 工作流；

接到一个新的项目需求，第一步的工作是创建一个特性分支（feature），分支的命名规则一般1~2个单词，不要使用缩写，尽可能保持字面意思，让别人看懂，分支需要被推送到中央版本库；

主要负责该需求的程序员在该分支上开发，谨记经常提交代码，确保代码不要遗失，如果有共同合作人，应该尽可能频繁地把变更推送到中央版本库，确保合作人能尽可能早地知道你的变化；

应该至少每天同步（sync）一次主干的变化，方法是在你的分支下，首先执行git fetch将远程代码下载到本地，然后执行git merge master或者git rebase master，（推荐后者，可以产生线性的提交历史，不强制）；

特性开发完毕后，提交代码到中央版本库，commit message按照规范关联需求，测试平台会自动生成对应的测试任务，辅助以提测邮件自动通知测试进行测试；

测试到发布

测试对分支进行测试和集成测试；

分支测试完毕后，开发人员将分支提交merge request到主干，由系统的研发负责人进行一次code review并同意合并主干。因为merge会产生一个commit，强制留痕，可以帮助我们记住一个特性分支是何时添加到主干的；

一旦一个分支合并入主干后，约定分支不会被再次使用，如果该分支合并主干后有bug，则重新拉取分支进行修复；

测试对此时的主干进行回归测试；

测试完毕后（包括修完bug），测试或开发（优先由测试操作）对master打tag，并完成发布；

Feature发布后

合并主干或发布完成后，如果突然出现了紧急运营问题或者bug，应该从最新的主干分支创建分支，分支命名规则为quickfix开头；

在quickfix分支上修复bug，完毕后，紧急验证；

验证完毕后，将quickfix分支合并master分支打tag，并发布线上；

发布完毕后，quickfix_feature1分支不再重复使用；

研发全流程

定期清理中央仓库分支

定期清理中央仓库Tag

git命令

清理所有旧分支

git branch --merged origin/master | egrep -v "(^\*|master|dev)" | xargs git branch -d
git branch -r --merged origin/master | egrep -v "(^\*|master|dev)" | sed -e 's/origin\///g' | xargs -n 1 git push  origin --delete
git fetch -p

清理本地已经合并到master分支的无用分支

git branch --merged origin/master | egrep -v "(^\*|master|dev)" | xargs git branch -d

清理远程已经合并到master分支的无用分支

git branch -r --merged origin/master | egrep -v "(^\*|master|dev)" | sed -e 's/origin\///g' | xargs -n 1 git push  origin --delete

如果远程分支已经被删除,则清理本地的分支追踪.

git fetch -p

代码分支管理.md 3.3 KB 히스토리 Raw