做网站能用微软,广州十大家装品牌,jsp网站开发教程,哈尔滨seo推广四、标签管理
4.1、标签的理解
在使用 Git 进行版本管理时#xff0c;**标签#xff08;Tag#xff09;**扮演着非常重要的角色。它其实就是对某次提交#xff08;commit#xff09;的一个简洁标识#xff0c;相当于给这次提交起了一个可读、易记的“别名”。比如…四、标签管理
4.1、标签的理解
在使用 Git 进行版本管理时**标签Tag**扮演着非常重要的角色。它其实就是对某次提交commit的一个简洁标识相当于给这次提交起了一个可读、易记的“别名”。比如当项目发布一个正式版本时通常会在最后一次提交上打上像 v1.0 这样的标签以此来标识版本的里程碑。
标签的出现解决了一个非常实际的问题commit id 过长且难以记忆。虽然 commit id 唯一且精确但当我们想要回到某个重要版本、修复 bug 或对比差异时记忆一串哈希值显然不太现实。而标签为我们提供了一个更直观、更友好的方式。
举个例子 当你需要将项目回退到上一次发布的 v1.0 版本时只需执行类似
git checkout v1.0
就能瞬间定位到对应的提交。这比手动复制粘贴 commit id 简单得多。
因此标签不仅是对代码的一次快照更是项目迭代过程中的一个个“路标”。它让我们能更清晰地管理和回溯不同的版本阶段尤其是在团队协作或发布流程中标签的使用显得尤为关键。
4.2、标签的使用
创建标签
想要进行创建标签时首先需要切换到要进行打标签的分支上然后进行执行下面的命令
git tag 想要进行打标签的名称
默认进行打标签是打在最新提交的 commit 上的想要在指定的commit 上进行打标签如何进行呢
通过下面命令先进行产看指定的提交
git log --prettyoneline --abbrev-commit
然后通过
git tag 想要进行打的标签名称 指定的commit ID
Git还提供可以创建带有说明的标签用-a指定标签名-m指定说明文字字格式为:
git tag -a [name] -m XXX [commit_id]
查看标签含义
git show 标签名
删除标签
git tag -d 标签名
推送本地标签到远程仓库
推送指定的标签到远程仓库
git push origin 标签名称
推送所有的标签到远程仓库
git push origin --tags
进行删除推动送到远端的标签
删除推送到远端的标签一般分为两步
1. 先进行删除本地的标签
直接执行上面介绍过的删除标签的命令。
2. 将本地的标签进行推送到远程仓库
git push origin :标签名称
五、多人协作
5.1、在同一分支下进行多人协作开发
1.在gitee上进行创建分支dev分支 2.查看远程仓库的分支
git branch -r
如果没有看到在远程仓库上新建的分支进行执行pull命令进行拉取。
3.在本地进行创建分支并且和远端的分支进行建立联系
git checkout -b dev origin/dev
为了进行模拟多人协作开发即在Linux下进行创建了本地分支并且进行连接到远程分支上又在window 下进行创建本地分支模拟协同开发
Linux下进行模拟一个开发人员 widow 下进行模拟一个开发人员 在同一分支下进行开发的步骤如上图所演示的
目的我们开发者人员首先需要在dev分支上进行开发后在进行合并到远端的maser分支上。
首先每个开发者都需要先进行克隆远端仓库前提条件并且在远端仓库进行创建一个dev分支。
然后进行创建分支并且进行连接远端仓库
git checkout -b dev origin/dev
然后每个开发者都进行添加并提交对于代码文件的修改并推送到远端仓库中这个过程是有很大概率是冲突的需要进行解决冲突
最后就是将dev分支进行合并到master总分支上
有两种方如下
第一种是在远程仓库中进行填写合并表单的形式推荐
通过填写合并分支的表单然后通过审查人员在企业中一般是leader的审查后没有问题的话直接就将dev分支进行了向master进行合并。
第二种方式就是通过命令行的形式
首先需要在本地master 分支下进行pull拉取一下。
在参与的7开发者的本地进行合并master分支这个过程是可能有冲突的防止在mater上进行解决冲突出现BUG 问题。
最后在重新切换到master分支下进行合并dev分支。
总结一下其实在同一分支下进行多人协作的流程是这样
首先试图用git push 进行推送自己的修改如果推送失败则可能是远程仓库相对于本地仓库更新需要执行 git pull 试图合并如果合并有冲突需要进行解决冲突然后进行git push 推送到远程仓库最后进行删除分支
注意其实多人在同一分支下进行协作开发的场景是很少的可以说是几乎不存在因为多人在同一分支下进行开发基本进行git pull 进行合并的时候都是由冲突的而且进行解决冲突是一件非常麻烦的事情我们通常都是是使用在不同分支下进行多人协作开发。
5.2、在不同分支下进行多人协作开发 一种方式进行实现利用可视化的方式在远程进行创建分支 1.在远程仓库进行新建两个分支 feature-1和feature-2 2.不同的开发者在本地进行创建分支并且和远程分支进行建立联系 3.分别进行向远程分支进行添加推送 4.将远程分支中的内容进行合并到主分支中合并逻辑在下面进行演示 另一种方式进行实现全部进行使用命令行的形式
1.不同的开发者在本地进项创建分支和文件进行提交 2.然后推送到远端仓库
git push origin 想要进行推送到远端仓库的名称 在进行向远端仓库进行推送的时候由于我们是还没有进行创建远端仓库的直接进行执行push命令是不能进行成功push的在进行执行push的时候需要进行执行上述命令代表创建远程仓库并进行将本地仓库进行推送到该远端仓库。
3.另一个开发者也是这样的操作 在进行执行合并分支的逻辑之前在不同的分支下进行多人协作开发是没有经历到冲突的。
假如说我们的小伙伴由于每天进行加班肝的太严重了住进了医院但是他的开发还没有完成我们需要进行从本地仓库中进行将他的分支进行拉取下来替他进行开发维持项目的进度 1.想要对他的代码进行开发首先要进行找到小伙伴的代码 git push 这里进行拉取既可以进行拉取本分支的内容建立联系还可以进行拉取仓库中的内容 2.然后在本地进行创建分支并进行建立联系 git checkout -b 分支名 origin/远程仓库分支名 3.将开发的代码进行提交并推送到远程仓库中 执行git三板斧的操作 小伙伴康复回归重新进行开发 将本地分支和远程分支进行建立联系
git branch --set-upstream-toorigin/远程分支 本地分支
然后进行拉取
git pull 4.进行合并分支 将上面步骤直接进行总结成
切换至 master分支, pull ⼀下保证本地的master是最新内容。合并前这么做是⼀个好习惯切换⾄ feature-1 分支, 合并 master 分支 这么做是因为如果有冲突可以在feature-1分支上进行处理⽽不是在在master上解决冲突。 这么做是⼀个好习惯 由于feature-1分支已经merge进来了新内容为了保证远程分支最新所以最好push⼀下。要 push 的另⼀个原因是因为在实际的开发中master的merge操作⼀般不是由我们自己在本地进 其他⼈员或某些平台merge时操作的肯定是远程分支所以就要保证远程分支的最新。 如果 merge 出现冲突不要忘记需要commit才可以push!!切换至 master 分支合并feature-1分支将master分支进行推至远端最后将分支进行删除
5.3、解决gitbranch-a 进行打印已经被删除的远程分支
先执行下面命令进行查看远端分支
git remote show origin 进行在本地也进行删除远端被删除的分支
git remove prune origin 六、 企业级开发模型
6.1、企业级开发流程
一般流程 在企业中我们要进行上线一个软件要经历以下历程 开发 → 测试 → 发布上线 其中开发又包括 规划、编码、构建发布包括发布、部署和维护。 其中
开发团队 : 写写写根据业务需求进行实现测试团队测测测对开发人员的代码进行测试运维团队稳稳稳维持服务器的稳定
通过上面的介绍可以看到开发团队和运维团队是存在利益冲突的
DevOps打破“开发”和“运维”的隔阂
在传统的 IT 组织里开发团队 (Dev) 和 运维团队 (Ops) 常常存在不同的诉求和目标。 开发这边尤其是敏捷团队更看重快速的交付和频繁的变化而运维那边最关心的是线上环境的稳定。 这两边如果各做各的往往就会出现“部门墙”——开发想要快速上线新功能运维却得控制风险和变更。 结果呢大家都不开心IT 的整体价值也打了折扣。
为了解决这个矛盾DevOps 这个概念就应运而生了。 DevOps 是 Development开发 和 Operations运维 的组合词它不仅仅是一个工具或者流程而是一种文化、运动、一套最佳实践。 核心目的很简单让开发和运维能更好地沟通、合作尽可能多地通过自动化来打通从开发到上线的流程让软件的交付速度更快、发布更可靠。
从大流程来看DevOps 贯穿了 计划 → 编码 → 构建 → 测试 → 预发布 → 发布 → 运维 → 监控 这套流程真正做好的话能显著加快我们的软件交付减少线上事故的风险提升用户体验。 DevOps 跟咱们的 Git 有啥关系
说了这么多DevOps 到底和咱们平时学的 Git 有啥关系 其实非常直接 软件的每一次迭代本质上就是在改动代码代码管理 就成了核心问题。 不管是做自动化测试、自动化部署还是回滚 Bug 修复代码版本管理都离不开。 而 Git作为当前最流行的分布式版本控制系统简直就是 DevOps 流程里的“血液”。 它让我们能够在多次迭代、多版本并行的情况下依然有条不紊地管理代码也给后续的自动化流程比如 CI/CD打下了最坚实的基础。
所以Git 不光是咱们开发过程中“个人必备工具”更是整个 DevOps 体系里不可或缺的基石。 有了它咱们的迭代才能真正快又稳才能让 DevOps 真正发挥它的威力
6.2、系统开发环境
在咱们日常做系统开发的时候环境管理是绕不开的一块。平时我们会遇到好几种不同的环境每个都有自己的用处下面给大家聊一聊
开发环境
就是我们日常撸代码的环境。一般来说开发环境的容错和提示都开得很全各种错误信息、调试工具都开着目的就是让开发更顺畅出错能立马定位。
测试环境
测试环境的作用可不小。咱们写好的代码不能直接上线吧必须在测试环境先跑一跑确保基本没啥问题。测试环境就像是代码上线前的“体检中心”。
预发布环境
别小看了它很多公司都会单独搞个预发布或者叫灰度/仿真环境尽量模拟生产环境的配置提前找出线上可能出现的坑。它一般是和生产环境非常像但又独立出来的专门用来让咱们发版更安心。
生产环境
这个不用多说就是用户能直接用到的“正式版”环境所有线上跑的服务都在这。对用户来说看到的都是生产环境的服务。
从大的流程上来说咱们的项目一般会走 开发 → 测试 → 上线。 如果公司规模再大点可能还有更多比如仿真环境、灰度环境、多个版本的测试环境……都为了让上线更靠谱。 重点来了 一个项目从想法到成功测试是绕不开的。完善的测试体系能让我们在上线前解决绝大部分致命 Bug虽然测试不直接产生收益但它才是产品质量的最后一道防线。也能反映一个团队、一个公司的成熟度。别看它不“显眼”能不能搞好测试往往决定了项目能不能成
6.3、Git分支设计模型
在前面聊到的多环境开发、测试、预发布、生产和 DevOps 流程中代码管理 是非常核心的一块。而对于代码管理Git 是我们的得力助手。 但是光有 Git 还不够。要让多人协作高效、避免踩坑就得有一套合理的 分支模型。下面分享一个企业中常用的 Git 分支模型通常也被称为 Git Flow。
不同岗位对分支有不同的需求
开发人员 自然是在“开发分支”上写新代码
测试人员 则更想要一个单独的分支能随时拿到他们需要测试的版本。 所以为了让大家各司其职又能高效协作咱们就得好好设计一个合适的 Git 分支模型。
常用分支及适用环境
分支名称适用环境master主分支生产环境release预发布分支预发布/测试环境develop开发分支开发环境feature需求开发分支本地开发hotfix紧急修复分支本地修复
这套分支和环境的搭配只是常见的一种实践不是“放之四海而皆准”的真理。每个公司、每个团队都可能有不同的调整。 各分支的职责
master 分支 只读、唯一直接关联到线上生产环境。 一般只从 release 分支合并而来所有代码都非常稳定。 发布上线后要打上 tag标签来方便追溯。 禁止直接在 master 分支上开发。
release 分支 预发布分支给测试人员用来做全面测试。 基于 develop 分支创建合并了所有 feature 分支的内容。 命名方式release/版本号_时间戳比如 release/v1.2_20250610。 这个分支是临时的等发布完成后可选择删除。
develop 分支 统一的开发分支永远保持最新的可用代码。 所有 feature 分支开发完成后都要合到这里不能直接在上面开发除非是特别小的修改。 也是后续发布 release 分支的基础。
feature 分支 针对具体新需求或功能点的开发分支。 命名方式feature/功能_作者_时间比如 feature/login_ys_20250610。 开发完合到 develop 分支功能上线后可删除。
hotfix 分支 用于线上版本的紧急修复补丁。 直接基于 master 分支创建。 命名方式hotfix/问题_作者_时间比如 hotfix/crashfix_ys_20250610。 修复完成后要合到 master 和 develop 两个分支并推送远程修复上线后即可删除。 Git Flow 模型适用不等于万能
其实上面介绍的就是很多企业常用的 Git Flow 分支管理模型。它能很好地满足多环境、多人协作的需要让每个角色都能在各自的分支上做事流程清晰可控。 不过Git Flow 也并非“唯一解”。如果你所在的团队是做 持续交付 的或者更想简化流程也可以尝试更轻量的模型比如基于主干的开发模式Trunk-Based Development、使用特性标志Feature Flags等等。
关键是 不要盲目追随别人的分支模型 要根据自己团队和项目的情况去选适合自己的方式
因为分支模型最终的目的就是让咱们的软件开发和协作更高效、更安全。工具、流程再好也得服务于人的需求才算真正有价值。
Git flow模型并不是所有的公司都进行使用的很多公司使用自己独立开发的模型例如阿里的飞流flow分支模型不同的团队的需求不同进行选择的分支模型就不同。
七、企业级项目管理实战
创建模型的时候进行选择master feature分支 企业名称可随意填写⼀个测试名称只要能通过即可。注意多⼈协作开发需要将多⼈账号拉⼊⼀ 个企业下才⾏。如何添加成员后⾯会跟⼤家讲解。
创建项目 创建仓库 注 创建的仓库可以关联到某个项⽬中被管理
添加成员
1. 添加企业成员 申请后需要审批人员进行同意方可加入。
2.添加项目成员 3.添加仓库成员 开发场景-基于git flow模型的实践
新需求的加入
现有一个订单管理的新需求进行加入首先可以基于 develop 分支创建⼀个 feature/hyb_order_20231012 分⽀。 1. 需求在 feature/hyb_order_20231012 分⽀开发完毕这时研发⼈员可以将代码合并到 develop 分支将其部署在开发环境的服务器中方便开发⼈员进行测试和调试。
a. 开发者在 feature 分支下发起请求评审 b.审查员进行审核代码 c.审查通过进行合并分支 d.合并成功进行查看结果
2.在develop 下开发人员自测通过后先确定下 develop 不存在未测试完毕的需求然后研发人员可基于 develop 分支创建⼀个 release/xxx 分支出来可交由测试⼈员进行测试。 3.测试⼈员测试 release 通过后包含测试环境和预发布环境的测试就可将代码合并入 master。 4. 测试⼈员在 master (正式环境) 测试通过后便可删除 feature/xxx 分支。 修复测试环境 Bug
当 develop 分支的测试环境出现 Bug建议大家直接在 feature 分支 上进行修复。
修复后的提测、上线流程与新需求的加入流程一致确保在开发阶段就保持分支的健康和可控性。 修复预发布环境 Bug
当 release 分支的测试环境出现 Bug修复步骤如下
回归检查先检查 develop 分支 是否也存在该 Bug。 修复流程 如果 develop 分支 也有该问题修复流程与测试环境 Bug 修复一致 如果 develop 分支 没有该问题这种情况一般比较少往往是数据兼容问题或者环境配置问题需要单独定位和解决。 修复正式环境 Bug
当 master 分支的正式环境出现 Bug修复步骤如下
回归检查先检查 release 分支 和 develop 分支 是否同样存在该问题。 修复流程 如果存在修复流程与测试环境 Bug 修复流程一致 如果不存在这种情况也比较少大多是数据兼容问题或者环境配置问题需要重点排查。 紧急修复正式环境 Bug
有时候Bug 在测试环节未能发现但在正式上线一段时间后才出现属于紧急修复 Bug。此时流程如下
建议先验证下 预发布环境即使有些企业在面对紧急修复时跳过了这一步。 基于 master 分支创建一个 hotfix/xxx 分支。 修复完成后发布到 master 进行验证。 验证完毕后将 master 代码合并回 develop 分支并删除临时的 hotfix/xxx 分支。
