【Git】第3期多人协作与企业级开发规范详解-北京尧图网络

目录开头一.多人协作1. 前期准备1用 windows 终端模拟多人2创建分支2.同分支协同开发1链接远程分支a.本地还没有相应分支b.本地已经存在分支2示例3.多分支并行开发1创建各自分支2示例4.远程分支的跟踪与清理二.企业级开发的背景认知1. 分工2.核心环境3.Git Flow 模型结尾往期回顾开头OK了我们今天这一期来学习Git分布式多版本管理器的最后一部分的内容——多人协作与企业级开发规范详解。废话不多说我们直接开始。一.多人协作1. 前期准备1用 windows 终端模拟多人在讲解Git多人协作之前我们现在使用 windows 的命令行窗口来代表另一个开发者可以在当前选定的目录下打开 windows 的终端将远程仓库克隆到本地来注意我们是模拟了两个⽤⼾实际开发中每个⽤⼾都有⾃⼰的gitee/github账号如果要多⼈进⾏协同开发必须要将⽤⼾添加进开发者⽤⼾才有权限进⾏代码提交2创建分支⽬前我们的仓库中只有⼀个 master 主分⽀但在实际的项⽬开发中在任何情况下其实都是不允许直接在 master 分⽀上修改代码的这是为了保证主分⽀的稳定。所以在开发新功能时常常会新建其他分⽀供开发时进⾏迭代使⽤。那么接下来就让我们在 gitee 上新建 dev 远程分⽀供我们使⽤如上图现在我们就在远程仓库上创建了一个dev分支2.同分支协同开发这是最简单的协作场景多名开发者共用同一个远程开发分支通常是dev分支直接在该分支上提交代码、同步更新标准协作工作流多人在同一分支开发时核心遵循「先拉取再提交最后推送」的原则完整流程如下开发前执行git pull origin 分支名确保本地分支和远程最新版本保持一致。在本地修改代码完成后执行git add、git commit提交到本地版本库。执行git push origin 分支名尝试将本地提交推送到远程1链接远程分支我们首先可以使用git branch -a查看所有分支可以看到现在本地仓库中还没有我们在远程创建的 dev 分支执行git pull拉取下来然后我们在本地也创建一个 dev 分支可以使用git branch -vv查看分支链接的一个状态如上图在本地的 dev 分支还并没有与远程的 dev 分支建立连接a.本地还没有相应分支git checkout -b 分支名 origin/分支名执行后本地就有了和远程同步的分支b.本地已经存在分支git branch --set-upstream-to origin/分支名分支名如上图windows 这一段也是一样的操作2示例现在我们在 Linux 这一段创建一个file.txt的文件然后现在谁送到远端如上图我们远端的 dev 分支就成功刷新了可是现在 windows 端还没有file.txt文件要执行git pull拉取一下这样我们就成功添加了 file.txt 文件现在我们在 Linux 下修改 file.txt 并且推送到远程如上图现在远程仓库就有了 Linux 下 dev 分支所添加的内容现在切换到 windows 下的 dev如上图我们在windows的 dev 分支下修改了 file.txt 文件可是 push 推送缺出现了问题这是怎么回事呢因为此时远程的 dev 已经被其他人进行了修改windows 下的 file.txt 不是最新的如果直接进行了 pushgit不知道报错哪一个会出现覆盖的问题解决步骤拉取远程最新代码并自动合并git pull origin 分支名git pull本质是两步操作的合并先执行git fetch拉取远程所有新提交到本地再执行git merge把远程提交合并到当前本地分支。2.处理合并冲突如有如果两人修改了同一文件的同一位置Git 无法自动合并就会标记冲突文件状态为both modified。打开冲突文件手动编辑保留最终正确代码删除、、冲突标记。执行git add 冲突文件标记冲突已解决。执行git commit -m 解决合并冲突完成合并提交。再次推送代码git push origin 分支名此时本地版本已经包含远程所有最新提交推送即可成功。开发好习惯每次推送前主动执行git pull可以提前发现并解决冲突避免冲突堆积后难以处理现在我们在 file.txt 文件中修改冲突然后再 push现在我们要让远程的 dev 和 master 分支合并3.多分支并行开发⼀般情况下如果有多需求需要多⼈同时进⾏开发是不会在⼀个分⽀上进⾏多⼈开发⽽是⼀个需求或⼀个功能点就要创建⼀个 feature 分⽀现在同时有两个需求需要你和你的⼩伙伴进⾏开发那么你们俩便可以各⾃创建⼀个分⽀来完成⾃⼰的⼯作1创建各自分支我们先在 Linux 创建 f1 分支建立连接下面在 windows 下创建 f2 分支现在 Linux 和 windows 代表不同的开发人员都有各自的 feature 分支各自开发互不影响2示例在Linux的 f1 下创建一个 file1.txt 文件并推送到远端windows 也是一样的正常情况下你俩就可以在⾃⼰的分⽀上进⾏专业的开发了但是如果有一天 windows 上的开发者生病了现在要求 Linux 下的开发者接替他的任务进行开发如上图通过git pull我们将 f2 分支拉取下来了现在我们要在本地也创建一个 f2 分支并且进行连接此时就可以帮助他进行开发现在他的病好了我们就可以在 Linux 下删除 f2 分支在 windows 下需要通过git pull来抓取变化如上图这样我们就可以进行同步现在我们可以尝试下合并对于 windows 的 f2 我们来使用一下pull request此时我们可以通过申请 PRpull request的方式进行合并4.远程分支的跟踪与清理本地分支和远程分支建立关联后这个本地分支就叫**「跟踪分支」**优势执行git pull、git push时无需手动指定远程分支名Git 会自动对应。常见建立跟踪的场景克隆仓库时本地master自动跟踪origin/mastergit checkout -b 分支名 origin/分支名新建本地分支并自动跟踪远程分支git branch --set-upstream-toorigin/xxx 本地分支给已有分支绑定跟踪关系查看远程分支状态git remote show origin标记为stale的分支就是远程已删除、本地还残留的过期引用清理过期引用git remote prune origin执行后本地所有失效的远程分支引用都会被清除git branch -a的结果就和远程仓库保持一致了二.企业级开发的背景认知1. 分工软件研发早期一个程序员可以完成从编码到上线的全部工作。但随着项目规模扩大团队开始精细化分工开发工程师Dev负责功能迭代诉求是快速迭代、频繁变更运维工程师Ops负责线上服务稳定诉求是减少变更、保障稳定两者诉求天然冲突于是催生了DevOps文化通过工具、流程、规范打通开发、测试、发布、运维全流程在保障线上稳定的前提下实现高效持续交付。而 Git 分支管理规范就是 DevOps 体系中代码层面的核心管控手段2.核心环境同分支对应不同的部署环境理解环境是理解分支规范的前提开发环境供开发人员日常编码、自测使用配置最灵活可以打印调试日志、开启测试工具是变更最频繁的环境测试环境供测试工程师做功能测试使用代码相对稳定。所有待上线功能都需要先在测试环境验证通过才能进入下一阶段。预发布环境配置、数据、服务都和线上生产环境完全一致是上线前的最后一道防线。用来发现「测试环境正常、线上却出问题」的环境差异类 bug生产环境正式对外提供服务的线上环境稳定性要求最高绝对不允许直接修改代码所有变更都必须经过完整测试流程才能发布对于规模稍微⼤点的公司来说可不⽌这么⼏个环境⽐如项⽬正式上线前还存在仿真/灰度环境3.Git Flow 模型Git Flow 是业界最经典的企业级分支管理模型它通过定义不同职责的分支对应不同的研发环境和阶段实现「稳定分支保线上、开发分支做迭代、临时分支做隔离」的分层管控五大分支的职责与规则分支类型定位分支来源合并去向生命周期命名规范master主分支对应生产环境初始创建-永久存在不可删除固定名称 masterdevelop开发主分支对应开发环境master-永久存在不可删除固定名称 developfeature单个功能开发分支developdevelop临时分支功能上线后删除feature/功能标识release预发布 / 提测分支developmaster develop临时分支版本发布后删除release/版本号_发布时间hotfix线上紧急修复分支mastermaster develop临时分支修复上线后删除master 主分支核心定位唯一、稳定、只读对应生产环境代码严格规则绝对不允许直接在 master 上开发、提交代码所有变更只能通过合并 release 或 hotfix 分支进入版本标记每次合并到 master 代表一次正式发布必须打上对应的版本标签tag比如v1.0.0方便版本追溯和回滚develop 开发主分支核心定位保存最新开发完成的代码对应开发环境规则所有新功能都从 develop 切出分支开发开发完成后合并回 develop。该分支始终包含下一个版本要发布的全部功能日常开发最频繁feature 功能分支核心定位单个需求 / 功能的开发分支每个新功能对应一个独立分支工作流从 develop 切出 → 功能开发 → 自测通过 → 合并回 develop → 删除该 feature 分支数量项目中可以同时存在多个 feature 分支对应多个并行开发的需求互不干扰release 预发布分支核心定位版本提测分支对应测试 / 预发布环境是发布前的缓冲分支触发时机当期所有需求都开发完成、合并进 develop 后从 develop 切出 release 分支交给测试人员测试规则release 分支上只修 bug不加新功能。测试中发现的问题直接在该分支修复修复过程中同步把修复代码合并回 develop保证开发分支同步更新收尾测试全部通过后将 release 分支合并到 master正式发布和 develop同步修复内容打 tag 后删除 release 分支hotfix 热修复分支核心定位处理线上紧急 bug 的临时分支触发时机生产环境出现严重问题需要立刻修复不能等到下一个版本发布工作流从 master 分支切出 hotfix 分支 → 修复 bug → 验证通过 → 合并回 master 紧急发布、同时合并回 develop 同步修复 → 打补丁 tag → 删除 hotfix 分支特点优先级最高不影响正常的开发迭代流程结尾Ok了我们Git学习就到这里了希望对你有所帮助。感谢你的点赞、收藏和关注我主页里有更好康的呦往期回顾【Git】第2期详解远程操作与标签管理【Git】第1期基本操作与分支管理详解【CMake】第4期 CMake测试

【Git】第3期多人协作与企业级开发规范详解

相关推荐

销售异议事件设计：Customer Quote、Context 与 Open Issue

鲸能云光伏集中监控系统的系统设计：多站汇聚、告警收敛与值守排班

开源大模型追踪：Meta Llama 5 ，靠生态碾压还是被国产反超？

更多资讯

记忆机制：对话内与跨对话的记忆

激光共聚焦显微镜：从原理到应用的全面解析

一文读懂Prometheus+Grafana监控体系（进阶篇）

关于ELK日志分析平台搭建（进阶篇），你需要知道的一切

Pinyon Shift 原生渲染器深度解析：从PM4命令流到EDRAM、Resolve与纹理解码的完整指南

英语副词详解

今日更新

GUI自动化测试中的ScreenLayout：从硬编码坐标到声明式画面地图

LLC谐振变换器12V25A 300W开关电源设计与调试全攻略

ESP32多应用Flash数据隔离：分区表与NVS namespace实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？