Git与Github学习版本控制和分支管理
Posted 黑黑白白君
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Git与Github学习版本控制和分支管理相关的知识,希望对你有一定的参考价值。
文章目录
*Git VS. Github
- Git是一个版本管理工具,可以在你电脑不联网的情况下,只在本地使用的一个版本管理工具,其作用就是可以让你更好的管理你的程序。
- 比如你原来提交过的内容,以后虽然修改了,但是通过git这个工具,可以把你原来提交的内容重现出来,这样对于你后来才意识到的一些错误的更改,可以进行还原。
- Github是一个面向开源及私有软件项目的托管平台,是一个网站,因为只支持Git 作为唯一的版本库格式进行托管,故名gitHub。
- 每个程序员自己写的程序,可以在github上建立一个网上的仓库,你每次提交的时候可以把代码提交到网上,这样你的每次提交,别人也都可以看到你的代码,同时别人也可以帮你修改你的代码。
- 这种开源的方式非常方便程序员之间的交流和学习。
1)版本控制
1、什么是版本控制?
版本控制系统是指对软件开发过程中程序代码、配置文件、文档等发生的变更进行管理的系统,它可以帮助团队更好的沟通协作,从而更好的进行交付,常见的版本控制系统分为集中式版本控制系统(如 SVN)和分布式版本控制系统(如 Git)。
- 为了避免团队使用混乱的分支,可以使用主流的分支策略题。
- 常见的分支策略有以下三种:GitFlow、GitHubFlow 以及 GitLabFlow。
2、分支管理有哪些?
2.1 GitFlow
GitFlow 是这三种分支策略中最早出现的。
2.1.1 GitFlow工作流简介
Gitflow工作流定义了一个围绕项目发布的严格分支模型,它会相对复杂一点,但提供了用于一个健壮的用于管理大型项目的框架,非常适合用来管理大型项目的发布和维护。
贯穿整个开发周期,master和develop分支是一直存在的,master分支可以被视为稳定的分支, 而develop分支是相对稳定的分支,特性开发会在feature分支上进行,发布会在release分支上进行,而bug修复则会在hotfix分支上进行,这样也有效避免了不同类型的开发工作在代码层级的耦合和干扰。
git-flow 的分支管理模型:
主分支
- master:master 对应着生产环境的代码。
- develop:develop 为开发分支,当 develop的代码达到稳定点并准备发布时,需将其合并至 master,然后使用版本号标记该次合并。
临时分支
不同于主要分支,临时分支的生命周期有限,当使用完后需将其删除,临时分支可分为:
- feature:功能分支,从 develop检出,必须合并回 develop。当开发某一功能时,从 develop 中检出 feature 分支,feature分支在开发未完成时一直存在,直到开发完后合并到 develop,然后删除该分支。
- release:预发布分支,从 develop检出,必须合并到 develop 和 master。预发布分支通常用于在发布到测试环境的代码,待测试完成后,合并到 develop 和master。
- hotfix:修复 bug 分支,从 master、release 中检出,必须合并回master、release,如果没有 release,就直接合并回 develop。如果在生产环境发现重大 bug,需要立即解决,可以创建
hotfix-x.x.x分支,然后开始解决问题。修复完成合并到 release 并删除 hotfix。
这些分支中的每一个都有特定的用途,并受严格的规则约束,即哪些分支可能是其原始分支,哪些分支必须是其合并目标。
2.1.2 GitFlow 的优缺点
- 优点:每个分支都有明确的定义,严格按照 GitFlow 管理项目代码的话,很难出现代码混乱;
- 缺点:如果特性分支过多的话很容易造成代码冲突,从而提高了合入的成本;由于每次提交都涉及多个分支,所以 GitFlow 也太不适合提交频率较高的项目。
2.1.3 GitFlow工作流优化
- hotfix和release的结果都要合并到master和develop中,为什么?因为它们的修改结果将持续影响这后续的开发和维护,必须合并以保证代码的一致性。
- 当线上项目需要版本回退,或者需要简单记录迭代版本时,我们常在master分支上打上 Tag 标签,例如:
- 功能发布:release_20190101_当月版本数
- BUG修复:hotfix_20190101_修复次数
2.2 GitLabFlow
GitLabFlow 出现的最晚,GitLabFlow 是开源工具 GitLab 推荐的做法。
GitLabFlow 支持 GitFlow 的分支策略,也支持 GitHubFlow 的“Pull Request”(在 GitLabFlow 中被称为“Merge Request”)。
- 相比于 GitHubFlow,GitLabFlow 增加了对预生产环境和生产环境的管理,即 Master 分支对应为开发环境的分支,预生产和生产环境由其他分支(如 Pre-Production、Production)进行管理。
- 在这种情况下,Master 分支是 Pre-Production 分支的上游,Pre-Production 是 Production 分支的上游;
- GitLabFlow 规定代码必须从上游向下游发展,即新功能或修复 Bug 时,特性分支的代码测试无误后,必须先合入 Master 分支,然后才能由 Master 分支向 Pre-Production 环境合入,最后由 Pre-Production 合入到 Production。
GitLabFlow 中的 MergeRequest 是将一个分支合入到另一个分支的请求,通过 MergeRequest 可以对比合入分支和被合入分支的差异,也可以做代码的 Review。
*常见的项目环境
一般项目都是分几个环境的:
- dev或本地环境
- test测试环境
- staging预发布环境
- production线上环境
dev环境主要是什么?
- 开发同学进行自测,进行功能流程串起来。
- 出现bug之后,进行bug修改及验证,提交代码到test环境。
test环境是什么?
- 测试同学重点关注的,进行新功能的测试,提交bug等都是依据test环境进行提交的。
- 进行老功能测试回归,bug回归等。
staging环境是什么?
- staging环境一般是产品同学进行验收,比如看一下开发同学是否按照需求来的,是否有大的问题可能没有考虑到。
- 进行到生产环境的预部署(包括sql兼容语句、UI页面或接口的提前上线等等)。
pro环境是什么?
- pro环境就是正式环境,一般就是我们说的线上环境。
2)版本控制工具
1、版本控制工具应该具备的功能
- 协同修改
- 多人并行不悖的修改服务器端的同一个文件。
- 数据备份
- 不仅保存目录和文件的当前状态,还能够保存每一个提交过的历史状态。
- 版本管理
- 在保存每一个版本的文件信息的时候要做到不保存重复数据,以节约存储空间,提高运行效率。
- 这方面 SVN 采用的是增量式管理的方式,而 Git 采取了文件系统快照的方式。
- 权限控制
- 对团队中参与开发的人员进行权限控制。
- 对团队外开发者贡献的代码进行审核——Git 独有。
- 历史记录
- 查看修改人、修改时间、修改内容、日志信息。
- 将本地文件恢复到某一个历史状态。
- 分支管理
- 允许开发团队在工作过程中多条生产线同时推进任务,进一步提高效率。
2、版本控制工具的种类
2.1 集中式版本控制工具:
CVS、SVN、VSS…
2.2 分布式版本控制工具:
Git、Mercurial、Bazaar、Darcs…
3)Git
请移步《【Git与Github学习(二)】Git的安装和使用》
4)GitHub
【部分内容参考自】
- 【尚硅谷】Git与GitHub基础全套完整版教程:https://www.bilibili.com/video/BV1pW411A7a5?spm_id_from=333.999.0.0
- Jenkins 配合 GitLab 实现分支的自动合并、自动创建 Tag:https://www.cnblogs.com/mycognos/p/10247648.html
- 使用git-flow分支管理模型和Jenkins多分支流水线的应用:https://juejin.cn/post/6963540509142810661
- Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow:https://juejin.cn/post/6984995032369463326
- 互联网公司的项目会分为哪些环境?:https://zhuanlan.zhihu.com/p/66343803
以上是关于Git与Github学习版本控制和分支管理的主要内容,如果未能解决你的问题,请参考以下文章