企业Git 规范的必要性

企业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标签相对应的代码状态,以准确地再现客户问题以创建
错误修复程序。 有时,较新的代码可能已经解决了该问题,但并非总是如此。
通常,您需要签出特定标签并从该标签创建分支:

六、Git常用操作

后续由团队成员逐步完善 。。。。。。

七、参考资料

<https://jaeger.itscoder.com/dev/2018/09/12/using-git-in-project.html
https://nvie.com/posts/a-successful-git-branching-model/> Git Flow
https://www.zhihu.com/question/36509119 git rebase 和
merge的优缺点https://www.cnblogs.com/marblemm/p/7161614.html
merge和rebase的适用场景及区别https://blog.csdn.net/cumj63710/article/details/107406830
Git的团队的6种最佳实践https://www.jianshu.com/p/ec38e27c09e6 最佳实践

本文由 在码圈 创作,如果您觉得本文不错,请随意赞赏
采用 知识共享署名4.0 国际许可协议进行许可
您可以自由的转载和修改,但请务必注明文章来源并且不可用于商业目的。
本站部分内容收集于互联网,如果有侵权内容、不妥之处,请联系我们删除。敬请谅解!
原文链接:https://bedebug.com/archives/git-norm
最后更新于:2021-08-03 15:12:12

请博主喝咖啡 ☕.