俗话说:没有规矩,不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性,不会显得杂乱无章,管理困难。Git分支规范也是一样。当遵循了某种约定的Git分支,在代码提交以及多开发、多分支协同工作的时候,必须遵循这个规范操作,否则不予以提交、合并代码、提测、上线等操作。
Git Flow有主分支和辅助分支两类分支,通常主分支也被称为长期分支。
主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。接下来我们着重讲一下分支问题。
注意: 一般来说,我们会选择将master分支和develop分支作为长期分支,长期分支是不会被删除的,会和你的project项目共存亡。即除非你project不再需要了,否则,这两个分支切出来以后就永远都不允许删除。当然也有一些特例,比如某些公司会将develop分支也进行删除,只保留master分支。
辅助分支是用于组织解决特定问题的各种软件活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作、以及对版本代码的测试。这些分支与主分支不同,通常只会在有限的时间范围内存在。这个有限的时间范围比如说一个开发周期,规定在两个礼拜,那么到了第二个礼拜的最后一天开发周期完成,代码合并,该分支就应该被删除掉。
辅助分支包括:
以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说,这些分支与Git其他分支并没有什么区别,但通过命名,我们定义了使用这些分支的方法。
使用规范:
使用规范:
使用规范:
分支 | 职责描述 |
---|---|
master | 运维人员:部署 |
develop | 开发人员:维护, 部署 |
release | 运维人员:部署 |
feature | 开发人员 :各模块自行创建、维护 |
bugfix | 开发人员 :修复bug,协助解决自动merge中发生的冲突 |
分支 | 环境 |
---|---|
master/hotfix/bugfix | 生产环境(release) |
develop | 开发环境(alpha) |
release | 预发布(RC)环境 |
结合了Gitflow和workflow两者,根据公司情况稍作改变。
分支 | 环境 |
---|---|
master | pre(作为预发布环境,只允许从dev分支合并到该分支) |
dev | perf环境(作为测试环境,只允许从feature分支合并到该分支) |
feature | sit环境(作为开发环境,允许开发直接从本地提交代码到该分支) |
分支命名规则:
feature分钟中,其中JID-1表示jira的id号,allenjol表示开发者英文名。
根据 angular 规范提交 commit, 这样 history 看起来更加清晰,还可以自动生成 changelog。
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
type
scope
subject
示例:
fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Document change on eggjs/egg#123
Closes #392
BREAKING CHANGE:
Breaks foo.bar api, foo.baz should be used instead
具体可查看文档
更详细的项目权限说明请参考官方文档:GitLab Project成员权限