网站数据分析,建立网站 英语怎么说,郑州网络营销学校,哪里可以学酷家乐设计Git大家都非常熟悉了#xff0c;就不做过多介绍#xff0c;但是如何用好Git、如何进行合理的分支开发、Merge你是否有一个规范流程呢#xff1f;#x1f4a4;
不论是一个团队一起开发一个项目#xff0c;还是自己独立开发一个项目#xff0c;都少不了要和Git打交道…Git大家都非常熟悉了就不做过多介绍但是如何用好Git、如何进行合理的分支开发、Merge你是否有一个规范流程呢
不论是一个团队一起开发一个项目还是自己独立开发一个项目都少不了要和Git打交道这些都是作为开发者必须要掌握的。每个团队也许有自己的Git工作流今天小许给你分享一个通用的流程和规范。
既然说到Git得先有个协同原则:
统一使用Git作为版本控制的主要工具。
统一使用GitFlow流程管理控制版本
基本命令操作
git add . 将变更从工作目录移至暂存区域
git commit -m “fix: xxx” 将暂存区中的文件提交到本地仓库中分支中
git pull用于从远程获取代码并合并本地的版本
git push用于从将本地的分支版本上传到远程并合并
这些操作命令在各个工作区、仓库之间如何进行流转的呢如下图 git有好几个区工作区workspace、暂存区indexStage、本地仓库local repository、还有远程仓库remote repository。
远程仓库为我们保存一份代码如github而工作区、暂存区和本地仓库都在本地
常用分支建议 前面简单讲了下代码提交流程但是版本控制并不是简单代码提交就完事了这里分享一些常用的分支开发但并不是任何项目都一定按照这种分支结构来定义按你的需求来确定需要哪些。比如你一个人开发一个小型项目那么就不用搞的那么复杂如果是多人协同开发版本迭代较快那么下面的分支内容会让你开发节奏更清晰合理
生产分支master
master分支是仓库的主分支也有人叫production分支这个分支包含最近发布到生产环境的代码最近发布的release 这个分支只能从其他分支合并不能在这个分支直接修改master 分支一般由release、develop以及hotfix分支合并任何时间都不能直接修改代码开发分支develop
这个分支是我们的主开发分支始终保持最新完成以及bug修复后的代码.包含所有要发布到下一个release的代码这个主要合并与其他分支比如feature分支一般开发的新功能时feature分支都是基于develop分支下创建的补丁分支hotfix
当我们在生产环境发现新的Bug时候我们需要基于master分支创建一个hotfix分支然后在hotfix分支上修复bug完成hotfix后我们要把hotfix分支合并回master和develop分支所以hotfix的改动会进入下一个release发布分支release)
当你需要发布一个新功能的时候要基于develop分支创建一个release分支在release分支做为基准进行测试并修复bug完成release后把release合并到master和develop分支release 分支为预上线分支发布提测阶段会release分支代码为基准提测功能分支feature
feature分支主要是用来开发一个新的功能一旦开发完成我们合并回develop分支然后提交合并请求到 release 分支进行提测。分支命名: feature/ 开头的为特性分支 命名规则: feature/user_module、 feature/cart_moduleGit工作流 上面那么多种分支类型而且不同的分支又是基于其他分支每次看完之后都记得但是结合起来发现仅仅停留在有印象是的我们不好从单纯的文字上理清分支之间的关系和合并方式。
没关系小许用个图把之间的关系梳理清楚 其实核心是要弄明白主干和各个开发分支的关系以及你的开发分支该和谁去合并。
不过还是那句话根据自己的项目和业务团队去指定Git工作不能为了更风去创建并不适合团队的分支不然会导致开发在无聊的敲命令花费时间在各种分支的合并上反而降低了效率。
适合别人的未必适合大家互相交流选择合适自己的
更多方位的流程大家可以看看这篇文章# 字节研发设施下的 Git 工作流
Commit编写规范 好的Commit messages 日志编写会带来极大的帮助它也反映了一个开发人员是否是良好的协作者更重要的是在后续修复bug和实现新的feture时对于之前实现的功能、解决的bug可以一目了然而不用通过阅读代码去了解曾经的实现因为这会是意见非常痛苦的事情
忘了说你的Commit messages会是Code Review人员参考基本你应该不想被无情的打回吧
目前社区有多种 Commit messages 的写法规范。来自Angular 前端框架规范是目前使用最广的写法比较合理和系统化。
其实浏览过Github开源项目的同学如果有注意Pull requests的话就有了解行我我们看下Angular的提交规范到底是咋样的为啥会成为参考标杆。 Commit messages提交可以参照以下格式
type: subject
BLANK LINE 空白行
body
BLANK LINE 空白行
footer
• type: 本次 commit 的类型诸如 bugfix docs style 等• scope: 本次 commit 波及的范围• subject: 简明扼要的阐述下本次 commit 的主旨在原文中特意强调了几点 . 使用祈使句是不是很熟悉又陌生的一个词来传送门在此 祈使句 . 首字母不要大写 . 结尾无需添加标点
• body: 同样使用祈使句在主体内容中我们需要把本次 commit 详细的描述一下比如此次变更的动机如需换行则使用 |
• footer: 描述下与之关联的 issue 或 break change
Commit Type的类别 • feat: 添加新特性
• fix: 修复bug
• docs: 仅仅修改了文档
• style: 仅仅修改了空格、格式缩进、都好等等不改变代码逻辑
• refactor: 代码重构没有加新功能或者修复bug
• perf: 增加代码进行性能测试
• test: 增加测试用例
• chore: 改变构建流程、或者增加依赖库、工具等
Commit messages格式要求 标题行50个字符以内描述主要变更内容
主体内容更详细的说明文本建议72个字符以内。 需要描述的信息包括:
• 为什么这个变更是必须的? 它可能是用来修复一个bug增加一个feature提升性能、可靠性、稳定性等等
• 他如何解决这个问题? 具体描述解决问题的步骤
• 是否存在副作用、风险?
如果需要的化可以添加一个链接到issue地址或者其它文档
来看这个这位老哥在Angular项目详细的commit信息大家可以对照上面的规范看可以用一个词描述这种好的Commit方式【“赏心悦目”】也许这也就是为什么这个项目的Commit会成为众多人模仿的原因吧 关于名词简称 软件团队中经常需要Git进行团队协作开发但是不少职场小宝朋友对于从大佬口中冒出来的一些字母缩略词一脸蒙蔽比如MR、CR这里一次说个明白让你不再迷茫各种简称哈哈
这里总结了一些
• CRCode Review. 请求代码审查。
• PR pull request. 拉取请求给其他项目提交代码。
• MR merge request. 合并请求
• ACKAcknowledgement. 承认同意。表示接受代码的改动。
• TL;DRToo Long; Didn’t Read. 太长懒得看。常见于README文档。
• WIPWork In Progress. 进展中主要针对改动较多的 PR可以先提交部分标题或 Tag 加上 WIP表示尚未完成这样别人可以先 review 已提交的部分。
• RFCRequest For Comment. 请求进行讨论表示认为某个想法很好邀请大家一起讨论一下
Git命令 在文章末尾分享一下收藏的一个非常全面的Git命令总结分享给大家
