企业Git 规范的必要性-阿里云开发者社区

一、Git 规范的必要性

既然认同需要一份 Git 规范，那么这个规范需要规范哪些内容，解决哪些问题

分支管理

代码提交在应该提交的分支 随时可以切换到线上稳定版本代码多个版本的开发工作同时进行

提交记录的可读性

准确的提交描述，具备可检索性 合理的提交范围，避免一个功能就一笔提交 分支间的合并保有提交历史，且合并后结果清晰明了避免出现过多的分叉

团队协作

明确每个分支的功用，做到对应的分支执行对应的操作 合理的提交，每次提交有明确的改动范围和规范的提交信息使用 Git 管理版本迭代、紧急线上 bug fix、功能开发等任务

二、分支管理

分支命名

master 分支

master 为主分支，主分支，永远处于稳定状态，对应当前线上版本

以 tag 标记一个版本，因此在 master 分支上看到的每一个 tag 都应该对应一个线上版本

master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码不允许在该分支直接提交代码

develop 分支

develop 为开发分支，始终保持最新完成以及bug修复后的代码, 包含了项目最新的功能和代码， 所有开发都依赖 develop 分支进行 一般开发的新功能时， feature分支都是基于develop分支下创建

小的改动可以直接在 develop 分支进行，改动较多时切出新的 feature 分支进行

推荐的做法: develop 分支作为开发的主分支，也不允许直接提交代码。小改动也应该以 feature 分支提 merge request 合并，目的是保证每个改动都经过了强制代码 review，降低代码风险

feature 分支

分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module 开发新功能时，以develop为基础创建feature分支 开发新的功能或者改动较大的调整，从 develop 分支切换出 feature 分支，分支名称为 开发完成后合并回 develop 分支并且删除该 feature/xxx 分支

release分支

发布分支，新功能合并到 develop 分支，准备发布新版本时使用的分支, 预发布

发布之前发现的 bug 就直接在这个分支上修复，确定准备发版本就合并到 master 分支，完成发布，同时合并到 develop 分支

当有一组feature开发完成，首先会合并到develop分支，当 develop 分支完成功能合并和部分 bug fix，准备发布新版本时或者进入提测时，会创建release分支如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线

hotfix 分支

分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似 当线上版本出现 bug 时，从 master 分支切出一个 分支，完成 bug 修复，然后将 合并到 master 和 develop 分支(如果此时存在 release 分支，则应该合并到 release 分支)，合并完成后删除该 分支 以上就是在项目中应该出现的分支以及每个分支功能的说明。 其中稳定长期存在的分支只有 master 和 develop 分支，别的分支在完成对应的使命之后都会合并到这两个分支然后被删除。简单总结如下： master 分支: 线上稳定版本分支 develop 分支: 开发分支，衍生出 feature 分支和 release 分支 release 分支: 发布分支，准备待发布版本的分支，存在多个，版本发布之后删除 feature 分支: 功能分支，完成特定功能开发的分支，存在多个，功能合并之后删除 hotfix 分支: 紧急热修复分支，存在多个，紧急版本发布之后删除

三、Git日志规范

四、分支提交操作建议

分支间操作注意事项

在团队开发过程中，避免不了和其他人一起协作，同时也会遇到合并分支等一些操作，这里提交 2 个个人觉得比较好的分支操作规范。

同一分支 使用 rebase

默认的 行为是 merge，可以进行如下设置修改默认的 行为： 不要在公共分支使用rebase 本地和远端对应同一条分支,优先使用rebase,而不是merge 关于使用rebase 还是 merge git rebase git merge 个人推荐大家开发的时候， 尽量及时rebase上游分支 （我习惯是每周merge一次），有冲突提前 就fix掉，即使我们自己的分支开发了很久（哪怕是几个月），也不会积累太多的conflict，最后合并进主分支的时候特别轻松， 非常反对从master check出新分支，自己闷头开发几个月，结果最后merge进主分支的时候，一大堆冲突，自己还嗷嗷叫的行为 尽量及时rebase上游分支，发现有冲突，merge

分支冲突解决建议

1. 首先使用git status 分析原因，是哪个文件出现了冲突，可以使用文本编辑器打开该文件。冲突产生后，冲突文件会显示以下标记<<<<<<< 与======= 之间是本地修改的内容， ======= 与

>>>>>>> 之间是远程修改的内容。 根据这个，对冲突文件进行编辑，在修改完之后， 重新commit以下就可以了

1. 如果我们确定远程的分支正好是我们需要的，而本地的分支上的修改比较陈旧或者不正确，那么可 以直接丢弃本地分支内容，运行如下命令(看需要决定是否需要运行git fetch取得远程分支)：
2. 如果我们觉得合并以后的文件内容比价混乱，想要废弃这次合并，回到合并之前的状态，那么可以 运行如下命令：

rebase过程中出现的冲突 在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突； 在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行: 这样git会继续应用(apply)余下的补丁 在任何时候，你可以用--abort参数来终止rebase的行动，并且"mywork" 分支会回到rebase开始前的状态。

五、最佳实践

设置好自己的提交用户名和邮箱

新功能重新建立功能分支 当您继续开发功能分支时，请经常根据master 分支对其进行重新设置。 这意味着要定期执行以下步骤， 这些步骤会在功能分支中 重写历史记录 （这不是一件坏事）。 首先，它使您的功能分支看起来像master 并进行了所有更新以达到master 要求。 然后，您对功能分支的所有提交都会在顶部重放，因此它们会顺序出现在Git日志中。 您可能会在一路上遇到需要解决的合并冲突，这可能是一个挑战。 但是，这是处理合并冲突的最佳方法，因为它只会影响功能分支。 解决所有冲突并进行回归测试之后，如果准备好将功能部件合并回master ，请再执行一次上述变基步骤，然后执行合并， 在此期间，如果其他人推动更改以master 与您的冲突，则Git合并将再次发生冲突。 您需要解决它们并重复进行回归测试

使用标签

完成测试并准备从master

分支部署软件后，或者如果出于其他任何原因想要将当前状态保留为重要的里程碑，请创建Git标签。分支积累与提交相对应的更改历史记录时，标签是该时刻分支状态的快照。

可以将标签视为无历史记录的分支，也可以将其视为指向创建标签之前特定提交的命名指针。配置控制

是关于在各个里程碑保留代码状态。

能够复制任何里程碑的软件源代码，以便在大多数项目中都可以在需要时进行重建。

Git标签为此类代码里程碑提供了唯一的标识符。 标记很简单：

考虑一种方案，其中与给定Git标签相对应的软件已分发给客户，并且客户报告了问题。

尽管存储库中的代码可能会继续发展，但通常需要回到与Git标签相对应的代码状态，以准确地再现客户问题以创建

错误修复程序。 有时，较新的代码可能已经解决了该问题，但并非总是如此。

通常，您需要签出特定标签并从该标签创建分支：

1. Git flow 规范

Git 作为一个源码管理的工具，不可避免的会涉及到多人的协作，协作必须有一个规范的工作流程，让大家有效的合作使得项目井井有条的发展下去。

工作流程在英语中叫 Workflow。

原意是水流，比喻项目想水流哪像自然的流动，不会发生冲击、对撞甚至旋涡。

Git flow 是最早诞生，并广泛采用的一种工作流，它采用了功能驱动开发（Feature-driven development，简称FDD），它指的是需求是开发的起点，现有需求再有功能分支

Git flow 最主要的特点有两个

1. 项目始终存在两个长期分支 master（主分支） 和 develop（开发分支）
2. 除此之外，还有三个短期分支 feature（功能分支）hotfix（补丁分支） release（预发分支）